<<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)
OTI Data Flow via DMaaP-MR (option 2)
OTI Components
- 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 (Opt 1) 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.
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>
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 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 | Resilency | Collector Resiliency Across Multiple Sites |
UC5 | Loadbalancing | 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 |
The candidate DCAE MS is snmp-polling or FOI to integrate with OTI.