...
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
...
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
...
- FLOW 4: Data is read from RunTime DB
2. PRE CONDITIONS
ONAP is ready & running:
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:
- ONBOARDED ARTIFACTS - (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.
...
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 PNF2.
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 the event onto DMaAP
VES Collector Publish on DMaaP – VES Collector publishes the event onto DMaAPVES Collector Publishes on DMaaP with the CMNotify Topic
...
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
...
PlantUML Macro | ||
---|---|---|
| ||
@startuml participant mSONAPComponent participant DMaaP participant RunTimeDB autonumber group RUNTIMEDB UPDATE hnote over mSONAPComponent : Info Update Notification mSONAPComponent -> mSONAPComponent : Determines xNF Update end group Run Time DB Writing hnote over mSONAPComponent : Notification mSONAPComponent -> DMaaP : Update Notification DMaaP -> RunTimeDB : Subscription hnote over RunTimeDB : Updates xNF Update RunTimeDB -> RunTimeDB : Updates xNF Information end @enduml |
...
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 – 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.
2. mS publishes on DMaaP – Publish onto DMaaP
(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.
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant Controller
participant DMaaP
participant RunTimeDB
participant xNF
autonumber
group RUNTIMEDB UPDATE
hnote over Controller : Config Update Notification
Controller -> Controller : xNF Config Update Needed
end
group Run Time DB Writing
hnote over Controller : DMaaP Notification
Controller -> DMaaP : Update Notification
DMaaP -> RunTimeDB : Subscription
hnote over RunTimeDB : Updates xNF Update
RunTimeDB -> RunTimeDB : Updates xNF Information
hnote over Controller: Send to xNF
Controller -> xNF : Sends config update to xNF
hnote over xNF: Updates Configuration
end
@enduml |
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.
PlantUML Macro | ||
---|---|---|
| ||
@startuml
participant RunTimeConfigDB
participant DMaaP
participant ONAPComponent
autonumber
group Run Time DB Reading
hnote over RunTimeConfigDB : Update Occurred
RunTimeConfigDB -> DMaaP : Publishes Notification
DMaaP -> ONAPComponent : Publishes Notification
hnote over ONAPComponent : Subscribes to Notification
ONAPComponent -> ONAPComponent : Updates Information
end
@enduml |
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 The mS publishes an event on to the DMaaP Bus.
3. Subscription to DMaaP – Subscription The interested ONAP component Subscribes to updates from RunTime Config DB from DMaaP
The ONAP Component Receives the update event RunTime Config DB Receives the event from the DMaaP Bus.
4. Updates DB ONAP Component updates info – The Database ONAP Component is updated
The RunTime Config DB ONAP Component is database is updated with the information updated configuration parameter that is needed.
4. Post Conditions
...
REFERENCES
Wiki Page for RunTime Db 5G CONFIGURATION (RunTime DB) CONFIGURATION PERSISTENCE SERVICE R6
Architecture component Description ARC RunTime DB Component Description - R6 Frankfurt
...