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 4 Next »


Why ConfigDB?

The OOF-SON implementations and the wireless technology (wt) implementations on SDN-R using external database to store different kinds of information.

This page shows some of the current stored info and its visualization in dashboards.

With respect to ConfigDB the following questions should be answered:

  1. What issue will a ConfigDB solve?
    1. It could act as "cache" for configuration data, so that other ONAP components do not need to request data directly from the network. Such concept potentially can reduce the number of active connections from ONAP to devices.
    2. more...
  2. What data should be stored?
    1. The name already defines already the scope. Configuration data should be stored only. As a consequence network status data must inquired from network always.
    2. The configuration data are data of the network/devices not the data of the controller or other ONAP components.
    3. Open: What about important status data - e.g life cycle, operational status, alarm status, device capabilities, ...)?
  3. Does ConfigDB store network actual or network target data?
    1. Both, there must be section to store the actual data and in the same format the target data, in order to view discrepancies in the network. Please see chapter 6.9 Application for Showing Aberrancies.
    2. The actual data is updated by controllers. The target data is updated by SO and ONAP design components.
  4. Which schema is used to store the data?
    1. good question (wink) → ConfigDB should differentiate technology agnostic data from technology specific data. 
      1. Examples for technology agnostic data: hardware inventory, software inventory - only those which are not stored in A&AI, device identifiers, device life cycle, neighbor relations
      2. Examples for technology specific data: frequencies, channel plans, interface capacities

Joanna Xu N.K. Shankaranarayanan @all: Please correct, update, comment, object, .....


CCSDK/SDNC/SDN-R/OOF-SON

Sandeep Shah Feel free to update this chapter (wink)


CCSDK/SDNC/SDN-R/WirelessTechnologies

As requested by Joanne Liu Rudel, this chapter will include a couple of dashboard views an their database representations. Please note that there are several discussion about moving some the data to other databases or at least align them with other databases (e.g. logging, A&AI).

Indices

The following figure shows the different indices and shards in a 3-node database cluster outside of CCSDK/SDNC.

Connect 

Connection information of expected devices (required network elements)  are stored in a database. Read more...

DashboardDatabase


Fault

As a kind of service for the dashboard the current network alarms and the alarm logs are maintained and stored in a database. Read more ....

DashboardDatabase


Maintenance Mode

SDN-R has the capability to suppress notifications northbound of the controller. Such configuration are stored and updated in a database. Read more ...

DashboardDatabase


Config

The actual device configuration data for wireless technology devices  data are currently stored only in the devices (read more ...), according to the concept "network as a database". 

The discussion around ConfigDB will change or add more functions to this concept. 

DashboardDatabase

The database is in the device.

The database is in the device.

The navigation to device data is derived from the management and control interface specifications. 


Inventory

All the inventory data, which are not modeled in A&AI are stored separately in a database. Read more ...

DashboardDatabase


ElasticSearch schema


  • No labels