What is ONAP?

In the previous blog, we understood what streaming telemetry is and how we can activate it on a juniper device to consume it on a collector or a package like openNTI. In this blog we will talk about what ONAP is and focus on two of the important components of ONAP , DCAE and DMaaP which are used in context of gathering telemetry data from VNFs and PNFs.

ONAP (Open Network Automation Platform) is an open source orchestrator and lifecycle management framework which was found by merging AT&T’s ECOMP (Enhanced Control Orchestration Management Platform) with OPEN-O (Open Orchestrator) under the Linux Foundation. The project aims at addressing the need for a common automation framework for service providers leveraging existing infrastructure and help simplify the operations. It provides a vendor agnostic controller and standard management, security and application interfaces while onboarding. With the rise in the use of SDN/NFV architectures, ONAP plays a perfect part helping complete lifecycle management, starting from onboarding the VNF to maintaining it and handling analytic information obtained from the VNFs. By doing so, it provides reliable service, ease of management, interoperability, and integration leading to the reduction in CapEx and OpEx costs. The architecture of ONAP is microservices based making it easier to deploy either through OpenStack or starting with the Beijing release using helm-based deployments upon Kubernetes (ONAP -OOM). ONAP provides a set of Northbound REST APIs that are open and provides interfaces allowing to support different environments. Through this, it allows users in realtime to reconfigure their network, services and capacity. This also allows for users to develop custom solutions with the use of open APIs.


Fig1: closed loop automation of ONAP


While ONAP itself is a huge platform to talk about, we could easily spends days in just getting introduced. In this blog we would touch upon the topics of interest with respect to integrating Juniper telemetry into ONAPs data collection and analytics project(DCAE) and how the data can be moved to the respective consumer using DMaaP

DCAE (Data, collection, Analytics, Events) is a project within ONAP which deals mainly with data collection, analytics, validation. It provides a framework for analysis of the raw data which are received from the VNFs and generate alerts to inform the rest of the eco system for subsequent operations. For example the subsequent operation may include creation of a new policy based on the occurrence of the previous event. There are 2 main collectors that we would be interested here within DCAE, they are VES collector and High volume VES collector(HV-VES). The HV-VES is more for the gRPC based streaming which has been contributed by Nokia in the Casablanca release and the standard VES collector was the part of the very initial Amsterdam release works based on REST APIs. Both of these follow a strict schema which defines how the data format should be in order to ingest any data into DCAE. The VES data format is discussed in the later section. Once the data is received within the collector, validation occurs and the data is sent to the analytics block where the data is analyzed based on defined control loops and model description. Once the data is stored in analytics, respective events, alarms are generated and sent to other ONAP components or external components.

screen shot 2019-01-27 at 1.10.47 pm

Fig2: DCAE architecture

DMaaP (Data Movement as a Platform) is another project within ONAP in conjunction to DCAE which helps transport the validated DCAE data to the rest of the components. DMaaP constitutes of Message Router (MR) which is event based pub/sub messaging service built on top of Kafka and zookeeper, Data Router (DR) which helps in the movement of files, Data movement director (DMD) which is a client to the DmaaP platform to publish and subscribe and finally data bus controller which provides the APIs to interact The MR based on the received events places them on the appropriate topic. The consumer would then pick the information from the respective topic and proceed with subsequent actions. For more information on MR, check out the below link on onap wiki.



Fig3: DMaaP architecture

VES (VNF Event Streaming) Data format:

Telemetry data formats and semantics / expected actions by management systems vary widely. For Fault Events, vendors use SNMP, 3GPP Corba, MTOSI, OSSJ etc, and semantics can differ (e.g. Critical Severity as “1” or “5”). For Measurement events (KPI/KCI), vendors deliver CSV or XML based files, with varying internal data formats. This variance results in substantial development and maintenance costs for device integration into management systems, typically 3-6 months development is needed. With VES streaming there is a significant reduction in effort to integrate telemetry into automated device management systems, by promoting convergence to a common event streaming format and collection system. The VES schema defines a set of mandatory fields and a set of additional fields with all the event types present with Common Event being common to all the data that we stream. There are various pre-defined event types such as the below present whose documentation and about the schema can be found in the link mentioned in references section.

Existing Optional Event Fields

faultFields otherFields voiceQualityFields
heartbeatFields sipSignalingFields


mobileFlowFields thresholdCrossingAlertFields

Below is the sample juniper syslog data being mapped to ONAP’s VES format. “syslogFields” is used for syslog data which is streamed from /junos/events sensor the rest of the sensors such as interfaces, linecards uses “otherFields”

Juniper Syslog Telemetry data in VES format

    "event": {
        "commonEventHeader": {
            "domain": "syslog",
            "eventId": "UI_CMDLINE_READ_LINE",
            "eventName": "syslog",
            "lastEpochMicrosec": 0,
            "priority": "Normal",
            "reportingEntityName": "vmx5",
            "sequence": 24,
            "sourceId": "65535",
            "startEpochMicrosec": 0,
            "version": 3.0

        "syslogFields": {
            "eventSourceHost": "vmx5",
            "eventSourceType": "router",
            "syslogFacility": 23,
            "syslogFieldsVersion": 3,
            "syslogMsg": "Not Available",
            "syslogTag": "NIL "

Juniper Line card telemetry data in VES format

"event": {
    "otherFields": {
      "otherFieldsVersion": 1.1000000000000001,
      "hashOfNameValuePairArrays": [
          "arrayOfFields": [
              "name": "mem-util-kernel-size",
              "value": "2147479528"
              "name": "mem-util-kernel-bytes-allocated",
              "value": "173348352"
   < ------ Trimmed ----------------------- >
              "name": "mem-util-kernel-mdi-allocations-failed",
              "value": "0"
          "name": "FPC0:CPU0"
    "commonEventHeader": {
      "eventId": "1",
      "reportingEntityName": "vmx5",
      "domain": "event",
      "lastEpochMicrosec": 4117135757,
      "sequence": 0,
      "sourceId": "0",
      "eventName": "/components/component/",
      "sourceName": "vmx5",
      "version": 3.0,
      "startEpochMicrosec": 4117135757,
      "priority": "Normal"

In the next blog we will talk about how Juniper devices can stream telemetry making VES as one of the options for data streaming format and work seamlessly with ONAP.

See you on the next part…if you like the blog and want to continue on journey of this telemetry packet” To boldly go where no telemetry packet has gone before”.

“Beam me out, Scotty”

Special Thanks to my Co-author of this blog post – Aravind Prabhakar

Leave a Reply

Your email address will not be published. Required fields are marked *