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.

UC#

Usecase Name

Description

UC1a

Add xNF_TYPE Configuration

Collection Task & xNF Configuration-driven for automatically data collection

UC1b

Add xNF instance

Support Real-time Data Collection for New xNF Instance

UC1c

Delete VNF instance

Suspend data-collection for deleted xNF instance

UC1d

Resiliency

Support Collector Resiliency Across Multiple Sites

UC1e

Load balancing

Support Load Balance Across Multiple Sites for polling based collectors

UC2a

Add xNF data Collection via DMaaP-MR

Support Collector Microservice data collection that doesn't have K8s's and Sidecar architecture case.

UC2b

DFC Integration

Integration with 5G BulkPM usecase (synthetic FileReady and distributed MR/DR )