...
- Flow 1 (Write) - VES Configuration information coming from PNF xNF 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 - Micro-Service or ONAP component writing & updating operational information
- Flow 4 (Read) - Data is read from RunTime Config DB
...
- RunTime Config DB
- Operations Specialist (ONAP user)
- Controller/ONAP Component, A&AI, VES collector/DMaaP
For more information and details you can visit the RunTime DB Use Case Wiki at: 5G CONFIGURATION (RunTime DB) CONFIGURATION PERSISTENCE SERVICE R6
OVERVIEW RUNTIME CONFIG DB
...
wiki describes a more detailed figure and description of the component.
PURPOSE OF RUNTIME CONFIG 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 Config 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.
...
- 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 (indirectly), 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.
...
ELEMENT SYNC - Software keeps the A&AI elements with the elements in the RunTime Config DB in Sync. . When the network first being established, a GetAllPNFs function from A&AI can be used on startup.
- 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.
- LOGIC - When a xNF appears is removed there is logic to determine how and when something is to be updated. There is some intelligence to know what elements of update.
INDEXING:
- INDEXING - Data Records will be indexed by xNF (VNF, PNF, ANF). It would be an objective to have a similar indexing mechanism as A&AI. May also need an index to be a logical object ID.
- RETRIEVAL - How are data records retrieved efficiently. This relates how the records are indexed.
The above diagram shows the usage of RunTime DB
...
1 INFORMATION FLOW DATA WRITTEN TO RUNTIME Config DB:
Information Flows show data being written to the Runtime Config DB
...
2 INFORMATION FLOW DATA READ FROM RUNTIME Config DB:
Information Flow from RunTime DB
...
- FLOW 4: Data is read from RunTime DB
Race Conditions - a hysteresis (a time difference) between writing information (from a Kafka broker) and a read request arriving before the writing has finished.
2. PRE CONDITIONS
ONAP is ready & running:
...
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.
Topology-type can be represented through the xNF associations in the schema
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
...
- 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 CM Notify - Writing to RunTime DB
The following UML diagram shows the Information Flow for RunTimeDB
...
A VES event (CM Notify) is received by the DCAE VES collector sent from the PNF
2. VES Collector – VES Collector gets the CM Notify
VES Collector gets the CM Notify
3.
A xNF determines that a configuration parameter needs to be updated, thus it triggers a CM Notify towards ONAP with the objective of updating the RunTime Config DB.
2. Publish on DMaaP – VES Collector publishes on the event onto DMaAP
VES Collector Publishes on DMaaP with the CMNotify Topic
43. Subscription on DMaaP – DMaaP RunTime Config DB gets the Notification
RunTime Config DB gets the Event and updates subscribes to the Event.
In the initial release (R6), the RunTime Config DB will use SDN-C's DMaaP listener capability; but the goal is that RunTime Config DB is a separate independent component so it would have its own DMaaP Listener.
4. Updates DB – The RunTime Config DB is updated with the information
The RunTime Config DB is updated with the information
3.1 FLOW 2: xNF Addition/Delete A&AI Update Flow - Updates to RunTime DB
...
AAI determines a xNF has been removed/added 3from the network. Thus, downstream ONAP components need to be aware of this change in the network.
2. AAI publishes on DMaaP – AAI publishes on DMaAP
AAI publishes on DMaaP 4A&AI Notify, that a xNF status has changed.
3. Subscription on DMaaP – DMaaP gets the Notification
RunTime Config DB subscribes to that event; and so, gets the AAI updates the information.
4. Updating the RunTime Config DB – The RunTime Config DB is update.
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. For a new xNF a pre-defined schema record is used for that xNF.
- (a) Some information may come from A&AI.
- (b) Other values will be discovered during operation.
- (c) Some information data may have default values defined in the schema.
3.1 FLOW 3: mS/Controller Operational Info Update Flow - Writing to RunTime DB
...
The describes the xNF information updates and keys based on xNF update.
3.
...
3 Flow
...
3
...
Description:
...
ONAP Component Writing to RunTime Config DB 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)The mS determines an update is necessary.
The micro service, (policy), controller, ONAP component during operation determines an update is needed and action needs to be taken.
When this happens, it will publish onto the DMaaP Bus. Composes policy guidance. When that request comes in the controller, makes a config change on the underlying xNF device, with a successful outcome, it then determines that an update to the Runtime Config DB needs to be updated.
(Controller/Micro-Service/ONAP component) determines that an update is needed > Controller TO xNF > NetConf Yang > Update RunTime ConfigDB
2. mS publishes on DMaaP – Publish onto DMaaP
The mS publishes an event on to the DMaaP Bus.
3. Subscription to DMaaP – Subscription from DMaaP
The RunTime Config DB Receives the event from the DMaaP Bus.
4. Updates DB – The Database is updated
The RunTime Config DB is database is updated with the information that is needed.
3.1 FLOW 4: Controller Sending Configuration Info Update Flow - Writing to RunTime DB
The following UML diagram shows Where a Controller (SDN-C, SDN-R) is updates the RunTimeDB because of a configuration parameter update.
During this flow a configuration update is also sent to the PNF or VNF.
This flow is used when a Controller determines that a Config change is needed. The Controller sends a message to the xNF (via Ansible, or NetConf). The Controller would then send an update on DMaaP which will then update the RunTime Config DB.
3.3 Flow 4 Description: Controller writes to RunTime Config DB Information Flow
1. Controller Determines Configuration Update Needed – The Controller determines an update is necessary.
The controller determines a configuration (parameter) update is needed and action needs to be taken.
2. Controller publishes on DMaaP – Publish onto DMaaP
The Controller publishes an event on to the DMaaP Bus.
3. Subscription to DMaaP – Subscription from DMaaP
The RunTime Config DB Receives the event from the DMaaP Bus.
4. Updates DB – The Database is updated
The RunTime Config DB is database is updated with the updated configuration parameter that is needed.
5. Controller sends to xNF – The Controller sends to xNF
The controller of the xNF updates the xNF with the configuration information. The xNF updates its internal storage.
3.1 FLOW 5: Reading from RunTime Config DB Info Flow
The following UML diagram shows reading information from the RunTime Config DB.
3.3 Flow 5 Description: Controller reads from RunTime Config DB Information Flow
1. RunTime Config DB has Update Needed – The Controller determines an update is necessary.
The RunTime Config DB determines a configuration (parameter) update is needed and action needs to be taken.
2. RunTime Config DB publishes on DMaaP – Publish onto DMaaP
The RunTime Config DB publishes an event on to the DMaaP Bus.
3. Subscription to DMaaP – The interested ONAP component Subscribes to updates from RunTime Config DB from DMaaP
The ONAP Component Receives the update event RunTime Config DB from the DMaaP Bus.
4. ONAP Component updates info – The ONAP Component is updated
The ONAP Component is database is updated with the updated configuration parameter that is needed.
4. Post Conditions
4a. Post Condition (Updated DB)
The post-conditions for the DB:
- Database is Updated - The RunTime Config DB has been successfully updated.
- Acknowledgement - A "ACK" (Acknowledgement) success or failure is returned to the requester. When a request from policy is updated, the DMaAP is posted that request is successfully completed which includes confirmation of NetConf parameters and runTime database updates. If this eventually becomes a database API, it will just be a simple success or failure message.
REFERENCES
Wiki Page for RunTime Db CONFIGURATION PERSISTENCE SERVICE R6
Architecture component Description ARC RunTime DB Component Description - R6 Frankfurt
...