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

Compare with Current View Page History

« Previous Version 13 Next »

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

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

High Level Architecture

OTI Architecture

OTI Data Flow via API (option 1) - consist of two components: OTI-event-proc microservice and OTI-handler microservice.  This option 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 (Option1).  Or publish 'dcae-collection-event' to DMaaP-MR (option 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. There is a LB in each K8s cluster sends this xNF collection request to a corresponding collector mS based on the LB algorithm. More detail


      OTI Data Flow via DMaaP-MR  (option 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).











 



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 and UC2 are targeted Use cases for Frankfurt.

UC#

Usecase Name

Description

UC1

Add xNF_TYPE Configuration

Collection Task & xNF Configuration-driven for automatically data collection

UC2

Add VNF instance

Support Real-time Data Collection for New VNF Instance

UC3

MS registration

DCAE Collector Microservice Registration

UC4

Resiliency

Collector Resiliency Across Multiple Sites

UC5

Load balancing

Support Load Balance Across Multiple Sites for polling based collectors

UC6

DFC Integration

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

UC7

Delete VNF instance

Suspend data-collection for deleted VNF instance








  • No labels