Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 13 Next »

Design Principals

  • the entire communication between SDN-R and CPS is via DMaaP
  • an exception might be when SDN-R uses CPS as lookup DB to complete a request to the network (lookup)




ONAP internal data  vs. Network Function specific data

For backup or Initial (startup) configuration CPS could store the configuration data according to the Network Function (VNP, PNF) specific data models. 

Such data is most likely not abstracted to be used for multi-vendor, multi-layer, multi-technology use cases and should/could not be used by µServices addressing such use cases.

Multi-vendor, multi-layer, multi-technology µServices require an abstract view of the network. Therefore a translation service is required to translate between ONAP internal data models and Network Function specific data models.

The database technology for the ONAP internal data must be well defined and so that model-translation-functions can be implemented accordingly. SQL based on in the MariaDB implementation seems to be the right choice.

The database technology for Network Function specific data depends on the data and the Network Function specific data schema. If the data model schema bases on YANG, which usually describes a data tree, then a non-SQL database, could be the right choice. 

Sequence Diagram

Status: under discussion 2020-03-01

  • No labels