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