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

STATUS: Draft

RunTime DB:

1 High Level Component Definition and Architectural Relationships 



The RunTime DB function provides storage for real-time run-time configuration and operational parameters that need to be used by ONAP.

2. API definitions

RunTime DB provides the following interfaces:

Interface NameInterface Definition Interface CapabilitiesVersionStatusConsumed Models
RTDBE-1RunTime DB Interface. 

An interface to create, update, retrieve, query, delete information from the RunTime DB. 

CREATE -

UPDATE -

RETRIEVE -

QUERY -

DELETE INFORMATION -


SDC (Controller) - RTDB DMaaP MR

Controller to RTDB RESTful API

DCAE VES Collector to RTDB DMaaP MR


ACCESS:

 - SO, DCAE, A&AI, Controllers (CDS, APPC, SDNC) will have default read/write access to RunTime DB

 - Other components will have default read-only access to RunTime DB but can be given access on a per record basis.




RTDBE-2RunTime DB Graphical User Interfaces 

Provides the capability to view and edit the data currently in the RunTime DB.

This GUI is meant to allow an operations user of ONAP to view the data stored in the RunTime DB during Run Time operation.




Note:   xxxI interface is a Component internal interface.  xxxxE interface is a component external interface

The current API documents can be found at:

RTDB consumes the following Interfaces:

Interface NamePurpose Reason For Use
SDCE-7

This interface is used to receive the service and resource artifacts (CSAR Package) from SDC.

This allows the RunTime DB to process the design-time Yang model artifacts onboarded.

STEPS:

(1) ONBOARDING - A vendor onboards artifacts describing the parameters supported for their PNFs and VNFs in xNF Package.

(2) SDC CATALOG - The onboarded artifacts are stored in the SDC Catalog after onboarding and validated (VNF-SDK).

(3) CSAR DISTRIBUTION - The contents of the artifacts are distributed by SDC in a CSAR package onto the DMaaP bus.

(4) SETTING UP RUNTIME DB - S/W to setup the RunTime DB using the content of the CSAR package consumes the SDC CSAR Package.


3. Run Time DB Component Description:

A more detailed figure and description of the component.

PURPOSE:

  • REPOSITORY -  The types of data that is stored in the Run-Time data storage repository for:

    • (1) CONFIGURATION PARAMETERS used by xNFs in run time. For example 5G Network run-time instance configuration information. and

    • (2) OPERATIONAL PARAMETERS used by ONAP and xNFs. Exo-inventory information is information that doesn't belong in A&AI.

  • DATA LAKE - It is designed to be a common services data layer which can serve as a data lake.
  • SYNCING - The RunTime DB enables the ability to sync data between ONAP & the xNFs. (The source of truth can be define).
  • CM FUNCTIONS - Enables OSS configuration, optimization, and LCM operations. (FUTURE)
  • CM FUNCTIONS - Enables future CM & Data management functions such as xNF Crash restoration, data restoration, data history management and auditing. (FUTURE)
  • CENTRAL/DISTRIBUTED - Because it is a common service, it is part of an ONAP installation, so it could be deployed with either an Edge ONAP installation or a centralized ONAP installation. (FUTURE)
  • SCOPE - The Run Time DB could also serve as the data storage to store for example ONAP Policy Rules, CLAMP Control Loop, Operational Views (FUTURE) and also accommodate other resources.

ACCESS (READ/WRITE):

  • READ ONLY - Run-Time parameters can be READ by any ONAP platform component and any ONAP plug-in. Examples of ONAP platform components are A&AI, SDC, SDNC etc.
  • READ/WRITE - Parameters can be READ/WRITE from Controllers, DCAE (future), VES Collector/DMaaP, A&AI, Policy/CLAMP (future) and other components with permission settings.

  • DEFAULT - SO (future), DCAE, A&AI, Controllers (CDS, APPC, SDNC) will have default read/write access to RunTime DB
  • DEFINABLE - Other components will have default read-only access to RunTime DB but can be given Read/Write access on a per record basis.

SYNCING (INVENTORY):

  • ELEMENT SYNC - Software keeps the A&AI elements with the elements in the RunTime DB in Sync. 

  • A&AI - A&AI is still the master of valid entities in the network and provides a dynamic view of the assets (xNFs) available to ONAP
  • RUN TIME DB - The RunTime DB is a master of the associate (exo-inventory) data associated with the entities.
  • DYNAMIC VIEW - When a xNF appears or is removed from the system, RunTime DB records will be added/removed based on A&AI entries.

INDEXING:

  • INDEXING - Data Records will be indexed by xNF (VNF, PNF, ANF).
  • RETRIEVAL - How are data records retrieved efficiently. This relates how the records are indexed.


4. Known system limitations


5. Used Models

RunTime DB uses the following models:

  • Inventory Model (Run time platform data model)


6. System Deployment Architecture



7. New Capabilities in this Release

This release, RunTime DB adds the following Capabilities:

  • In R6 Frankfurt.

8. References

  1.  
  • No labels