Page History

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

Summary

<<place holder for documenting the design to facilitate the  OTI feature addition in DCAE>>

...

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.

Table of Contents

High Level Architecture

OTI Architecture

OTI Data Flow via API (option 1)

Image Removed

      OTI Data Flow via DMaaP-MR  (option 2)

Image Removed

OTI Components

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).  

• OTIOTI-event-proc can:

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

...

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

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

• OTI-handler (Opt 1)  handler  can POST/Dispatch the ‘dcae-collection-event’ to a defined Kubernetes Cluster in a DCAE region based on xNF location . There is a 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.

        This will be useful for legacy microservices dependent on notification on OTI configuration change.

DCAE MS Impact

<include details for steps/interface agreement that MS should follow to leverage OTI feature>

   Option 1 - <LB, sidecar+mS interfaces - tba>

• Detail diagrams are in late section.

Image Added

      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.

Image Added

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).

Image Added

Image Added

Image Added

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.

Image Added

Image Added

Image Added 

Image Added

Use Case   Option 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)

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

...