1. Scope

DESCRIPTION: RunTime Config DB is a data lake repository for configuration and operational parameters. Run Time Config DB is a common service component that ONAP components can access write and read information to. The term "config" is used in the name for legacy purposes, but the use case is not limited to just configuration parameters and it is intended to be a repository for Operational parameters, and eventually policy information.

WHEN EXECUTED: This information flow is used during Run Time, when configuration or operational data is written to the Runtime Config DB.

• Flow 1 (Write) - VES Configuration information coming from PNF via e.g. CM Notify
• Flow 2 (Write) - New xNF is added or deleted from ONAP; A&AI notification xNF update
• Flow 3 (Write) - Controller writing & updating operational information
• Flow 4 (Read) - Data is read from RunTime Config DB

PURPOSE: RunTime Config DB serves as a data lake as a common service and data layer for ONAP components and micro-services.

INFORMATION PASSED: Configuration information (from CM Notify) or operational information (derived during ONAP operations).

ACTORS:

• RunTime Config DB
• Operations Specialist (ONAP user)
• Controller, A&AI, VES collector/DMaaP

For more information and details you can visit the RunTime DB Use Case Wiki at: 5G CONFIGURATION (RunTime DB)

OVERVIEW RUNTIME CONFIG DB

The: ARC RunTime DB Component Description - R6 Frankfurt

wiki describes a more detailed figure and description of the component.

PURPOSE OF RUNTIME DB:

• 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.
    

  • (3) POLICY INFORMATION - FUTURE - Policy, CLAMP Control Loops, Operational Views
• 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 TO RUNTIME DB (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 NEW xNF ADDED or DELETED (A&AI):

• 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.

The above diagram shows the usage of RunTime DB

It shows the four basic flows captured in the diagram.

• Writing information from a VES CM Notify event
• A&AI xNF addition/deletion
• Operational information written
• Information being read from the RunTimeDB

OVERVIEW RUNTIME CONFIG DB INFORMATION FLOW

Information Flows to Run Time DB or from RunTime DB during Run Time Operation of ONAP.

1 INFORMATION FLOW DATA WRITTEN TO RUNTIME DB:

Information Flows show data being written to the Runtime Config DB

New Information is written to RunTime Config DB from a Component or a Micro-service

The following three basic flows are described:

• FLOW 1: VES Event (CM Notify) Updates - Information flow
• FLOW 2: A&AI xNF (create/delete) updates - Information flow
• FLOW 3: micro-Service / Controller (SDN-R, SDN-C, APP-C, CC SDK) / other Component Updates for operational information - Information flow

2 INFORMATION FLOW DATA READ FROM RUNTIME DB:

Information Flow from RunTime DB

Other components are reading from RunTime DB.

Taking information from RunTime DB and using it to send to xNF components

• FLOW 4: Data is read from RunTime DB

2. PRE CONDITIONS

ONAP is ready & running:

• ONBOARDED ARTIFACTS - (future) If dynamic setup is used, definition artifacts are onboarded and used to setup the RunTime DB structures
• ONAP SOFTWARE - There is an ONAP installation. Software images loaded in OpenStack installation, where instantiation will happen (since no S/W image repository). Need to be available in Target Cloud Instances.

RunTime Config DB is setup (Design Time):

• RUN TIME DB SETUP - RunTime DB has been setup properly and is ready to be used.
• DESIGN TIME ACTIVITIES - Design time activities have happened (SDC service creation)

2.1 RUNTIME CONFIG DB DATABASE & STRUCTURE

2.1.1 DATA STRUCTURE (ONBOARDING & DESIGN TIME)

A data structure which is common for all different vendor xNFs will be used for the RunTime Config DB.

Domain oriented components can be used where all of those components share common information.

Any micro-service or ONAP platform component can define information in the data structure.

Before Run Time, the RunTime Config DB is setup with the appropriate data structures that it needs to work from SDC CSAR Service definition file package.

The Run Time Config is schema for the records RunTime Config DB are defined in advance. In the future (later releases) the RunTime Config DB schema may defined data structures on the fly.

DESIGN TIME - The schema of data structure of RECORDS the run Time Config DB can support are created and defined in advance.

RUN TIME - During Run Time the data and associations are DYNAMICALLY Run Time config DB updated using the schema of the records.

2.1.2 RUNTIME DB DATA LAYER

The RunTime DB is a Data layer common service data lake.

There has been quite a bit of discussion related to how to architect the RunTime DB component.

In R6 is was determined, that it should be a common service as a data layer to other ONAP components.

3. Information Flow

These four flows show the usage of RunTime DB

• FLOW 1: VES Event Updates (CM Notify) - Information flow
• FLOW 2: A&AI xNF (create/delete) updates - Information flow
• FLOW 3: micro-Service / Controller / Component Updates for operational information - Information flow
• FLOW 4: Data is read from RunTime DB

3.1 FLOW 1: VES Information Flow - Writing to RunTime DB

The following UML diagram shows the Information Flow for RunTimeDB

3.3 Flow Description: mS Information Flow

1. VES Event – VES Event Received

A VES event (CM Notify) is received from PNF

2. VES Collector – VES Collector gets the CM Notify

VES Collector gets the CM Notify

3. Publish on DMaaP – VES Collector publishes on DMaAP

VES Collector Publishes on DMaaP

4. Subscription on DMaaP – DMaaP gets the Notification

RunTime DB gets the Event and updates the information

3.1 FLOW 2: xNF Addition/Delete A&AI Update Flow - Updates to RunTime DB

The following UML diagram shows the xNF Update flow from updates in A&AI for RunTimeDB

In this flow, A&AI has determined that a xNF (PNF or VNF) has been removed or added to the network.

And so downstream dependent components need to update their information that a xNF has been removed/added.

In the case of RunTime, there would be a record for that xNF and it would be need to be removed/added

the basic mechanism of how this is done is reused (nothing new is introduced): A&AI publishes an notify event on DMaaP bus,

and RunTime (component) subscribes to that event and updates itself.

The describes the xNF information updates and keys based on xNF update.

3.3 Flow Description: AAI Update Information Flow

1. AAI Determines update – A xNF has been removed or added

AAI determines a xNF has been removed/added

3. AAI publishes on DMaaP – AAI publishes on DMaAP

AAI publishes on DMaaP

4. Subscription on DMaaP – DMaaP gets the Notification

RunTime DB gets the AAI updates the information

REMOVAL - RunTime DB removes the record for that xNF

ADDITION - If AAI determines that a new xNF is added to the network, then RunTime DB needs to setup a new record for that xNF with the default data structure and configuration. Default Configuration is setup. 

3.1 FLOW 3: mS/Controller Operational Info Update Flow - Writing to RunTime DB

The following UML diagram shows Where another ONAP component or Micro-Service updates the RunTimeDB

The describes the xNF information updates and keys based on xNF update.

3.2 mS Information Flow

3.3 Flow Description: mS Information Flow

1. Micro Service Determines Update Needed – fPackage.

There are multiple wayf system or any other conceivable way to deliver digital information.

2. PxY – Package is accepted into ONAP

the Vendor provided package is imported by a Technology Specialist/Asset manager into SDC.

4. Post Conditions

4a. Post Condition (Pre-onboarding)

The post-conditions for the pre-onboarding flow are the following. Once, pre-onboarded, the xNF is ready for onboarding.

• PACKAGE VALIDATED - VNF-SDK has successfully validated the package (as a result of pre-onboarding) and verified the content that VNF-SDK can perform validation on (See the VNF-SDK Validation section).
• Package SECURITY VALIDATION - The onboarding package is tested and validated for security.
• Artifacts SECURITY VALIDATION - The artifacts of the onboarding package are tested and validated for security.

4b. Post Condition (Onboarding)

The post-conditions for the onboarding flow are the following. Once, onboarded, the xNF is ready for service creation.

• Package SECURITY VALIDATION - The onboarded package is tested and validated for security.
• VNFD/PNFD MODEL LOADED - The xNF Resource's Descriptor model is visible in SDC.
• SDC INTERNAL PACKAGE EXISTS - The SDC Internal Package derived from the vendor provided xNF package has been successfully stored in SDC's catalog and is visible. All of the xNF artifacts, including the VES registration and PM dictionary/schema (for example) are visible and loaded properly.
• Internal Package Function Tested - The internal package function is tested and validated.
• ADDITIONAL ARTIFACTS - Additional manual artifacts can be incorporated into the Internal SDC xNF package.

REFERENCES

Wiki Page for RunTime Db 5G CONFIGURATION (RunTime DB)

Architecture component Description ARC RunTime DB Component Description - R6 Frankfurt

SUPPORTING FILES & SLIDES