( by Vijay Venkatesh Kumar, Wen Shang, Ashoke Sharma, Shrikant Acharya, Diana Zhang)
<<place holder for documenting the design to facilitate the OTI feature addition in DCAE>>
...
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.
| Table of Contents |
|---|
High Level Architecture
OTI Architecture
OTI Data Flow via API (Use Case 1) - consist consists of two components: OTI-event-proc microservice and OTI-handler microservice. This option 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).
...
-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 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. More detail 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.
...
- 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.
Option 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.
...