OTI Integration

( by Vijay Venkatesh Kumar, Wen Shang, Ashoke Sharma, Shrikant Acharya, Diana Zhang)

Summary

Network Topology can evolve over time, so there is a need for platforms to be able to receive these updates and take appropriate actions. From a DCAE standpoint, as new xNF gets instantiated, DCAE MS may need to be reconfigured to poll data from new sources. A new DCAE platform components – ONAP Topology Interface (OTI) will listen on external topology updates and determine MS to be reconfigured/instantiated and trigger updates via other DCAE platform components.

High Level Architecture

OTI Architecture

OTI Data Flow via API (Use Case 1) - consists of two components: OTI-event-proc microservice and OTI-handler microservice.  This user case not only can be used for real-time data collection, but also can support load balancing, auto scaling within the Kubernetes Cluster and Geo resiliency cross the regions (future release).  

• OTI-event-proc can:

-Subscribe topology events ( vendor-based-format or common-format-event) from  DMaaP-MR.

-Parse and process the event based on event-handler-template defined in Policy.

-Look up the xNF associated  data collection tasks defined in policy.

-Generate ‘dcae-collection-event’ that includes xNF instance topology and associated collection tasks. The ‘dcae-collection-event’ will be in VES like standard format.

-POST the ‘dcae-collection-event’ to OTI-Handler via API (US1).  Or publish 'dcae-collection-event' to DMaaP-MR (US 2).

-Store the ‘dcae-collection-event’ into ONAP-PG DB.

• OTI-handler  can POST/Dispatch the ‘dcae-collection-event’ to a defined Kubernetes Cluster in a DCAE region based on xNF location with low-latency.  A LB in each K8s cluster sends this xNF collection request to a corresponding collector mS ( with Sidecar)  based on the LB algorithm.  Below is the high level diagram. Detail diagrams are in late section.

      OTI Data Flow via DMaaP-MR  (Use Case 2) - a simplified solution that includes OTI-event-process microservice only. 

      OTI processes the topology information and publishes the 'dcae-collection-event' to DMaaP. Collector microservice shall be able to subscribe the event and to perform defined collection based on the 'dcae-collection-event' payload information.

Below diagram shows the details interfaces of OTI-event-process, OTI-Handler, load balances, sidecar, and collector microservices.

µS refers to a data collector microservices, e.g.  snmp-poller, FOI (sftp-file-collector), gRPC_collector (gNMI_client_collector).

Notes:

• MS must periodically look for files published under /otidata/process directory every 30 seconds (configurable) for the incoming OTI event update from sidecar.  MS updates the Task.json/OTI_config.json based the event and does the collection based on Task.json.
• MS should select statefulset (sidecar) checkbox property during onboarding (to indicate to platform it will be deployed as stateful set/OTI solution).
• MS is updated to call CBS API to retrieve the KV_Config in K8s.

Use Case 2 - DCAE MS (e.g. snmp-polling) shall subscribe 'dcae-collection-event' via DMaaP-MR and use the provided information ( vnf/pnf name, collection ip, collection tasks etc) for data collection.  DCAE MS shall publish the output data into DMaaP-MR.

Targeted Usecase (Frankfurt)

UC1a, UC1b and  UC2a are targeted Use cases for Frankfurt.