...

The RunTime DB is a Data layer common service data lake

3. Information Flow

These flows show the usage of RunTime DB

3.1

...

VES Information Flow

The following UML diagram shows the VNF/PNF Pre-onboarding FlowInformation Flow for RunTimeDB

@startuml
participant PNF
participant VESCollector
participant DMaaP
participant RunTimeDB 
autonumber 

group PNFRUNTIMEDB PACKAGE DELIVERYUPDATE
	hnote over PNF : CM Notification
	PNF -> VESCollector : CM Notification 	
end

group Run Time DB Writing
	hnote over VESCollector : VES Event
	VESCollector -> DMaaP : VES Event 
    DMaaP -> RunTimeDB : Subscription
	hnote over RunTimeDB : Writes Information
	RunTimeDB -> RunTimeDB : Write Information 
end

@enduml

3.

...

1 xNF Update Flow

The following UML diagram shows Onboarding Flow:

The following sections describe the above (UML) steps in more detail:

...

the xNF Update flow from updates in A&AI for RunTimeDB

@startuml
participant AAI
participant DMaaP
participant RunTimeDB 
autonumber 

group RUNTIMEDB UPDATE
	hnote over AAI : xNF Update Notification
    AAI -> AAI : Detects xNF Update
	AAI -> VESCollector : CM Notification 	
end

group Run Time DB Writing
	hnote over DMaaP : Notification
	AAI -> DMaaP : AAI 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.1 mS UPDATE Flow

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

@startuml
participant mS
participant DMaaP
participant RunTimeDB 
autonumber 

group RUNTIMEDB UPDATE
	hnote over mS : Info Update Notification
    mS -> mS : Determines xNF Update
	mS -> DMaaP : Notification 	
end

group Run Time DB Writing
	hnote over mS : Notification
	mS -> 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.2 VES Information Flow

3.3 Flow Description: PNxVERY

1. PNF PACKAGE DELIVERY – Vendor Delivers the Package.

There are multiple ways that a vendor could deliver a package. There is not SOL or any other kind of standard which specifies HOW a vendor shall deliver a package. There is no API, it could  be on a memory/flash drive or cloud shared delivery wayf system or any other conceivable way to deliver digital information.

...

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

3.4 Flow Description:

...

PACKxK)

3. LICENSE FILE CHECK LICExCK – VNF-SDK performs a license file check within the vendor-delivered PNF package.

4.CERTIFICATE FILE CHECKCxK – VNF-SDK performs a certificate file check within the vendor-delivered PNF package.

5.FILE AND DESTINATION CHECKFIxCK – VNF-SDK examines the MainServiceTemplate.mf (Manifest file) and performs a cross-check of the files & pathway directories specified within the manifest faile against the actual files within the vendor-delivered PNF package. It checks that the files that have been specified in the manifest file are actually in the given destination (directories).

6. MANIFEST FILE TAG VALIDATION MxN – VNF-SDK performs a check of the PNF keywords in the MainServiceTemplate.mf (Manifest file). The tags are pnf_product_name, pnf_provider_id, pnf_package_version, pnf_release_data_time, and non-mano_artifact_sets.

7. TOSCA METADATA FILE VALIDATION TOxON – VNF checks the Meta Data file (TOSCA.meta) in the PNF package with the ETSI SOL004 validation tags. The checks performed are the Entry definition, Entry-manifest, Entry-change-log, Entry-tests, Entry certificates.

8. USER CHECKS VALIDATION USxON – The end user may then inspect that the PNF package has been appropriately verified in the Certification studio.

3.5

...

FloxRDING

In the next steps, SDC brings that Vendor provided package into the SDC Catalog and creates an SDC internal representation of that package.

...

A. UUID IDENTIFIER – SDC adds a UUID identifier.

B.TOSCA METADATATOxATA – SDC adds additional TOSCA Meta-data.

C.TOSCA DESCRIPTORTOxR – SDC may add a TOSCA Descriptor

D. LICENSE MODEL FILE LICxLE – SDC can add a license model file.

E. ADDITIONAL ARTIFACTS ADxCTS – The User may optionally manually add additional artifacts.

...

PAxING

There are two options to onboard into SDC. OPTION #1 is to "automatically" onboard a package.

...

12. ONBOARD DESCRIPTOR - SDC transforms the xNF onboarding descriptor (PNFD or VNFD) into an SDC internal descriptor.

13. LICENSE MODEL FILES - License Model Files are added (optional).

PACKAGE ONBOARDING - MANUAL VNF VSP CREATION

The second option is to manually onboard into SDC, this entails the manual creation of a VNF VSP.

In this case, a VNF VSP model is manually created.

14. CREATE A VSP - The Technology specialist/Asset manager initiates a manual VSP creation.

15. INTERNAL MODEL - SDC is used to create an internal model with Metadata added.

16. INTERNAL DESCRIPTOR - The internal descriptor proprieties are updated. The vendor provided descriptor can specify attribute value limitations or ranges.

17. LICENSE MODEL FILES - The License Model Files are then added to the VSP

18. ARTIFACTS ADDED -  Finally, additional artifacts are added if necessary (optional).

CREATE RESOURCE - FROM A VSP

There are two ways to create a resource. A resource can be: (option 1) created from a VSP or (option 2) through manual creation.

These are the steps for creating a resource from a VSP.

19. CREATE VSP - The ONAP Operator requests for a resource to be created from a VSP.

20. RESOURCE MODEL - A VSP is transformed into a resource model.

21. INTERNAL DESCRIPTORS - The SDC Internal descriptor properties are updated. Customized types during design time allows service providers to specify additional restrictions on onboarded parameters. For example a vendor specified attribute might have allowed values 1 through 6; and customized types would restrict certain allowed values.

22. LICENSE MODEL FILES - License model files are updated in SDC.

23. ADDITIONAL ARTIFACTS - The operator may add additional artifacts to the resource. The resource becomes available in the SDC catalog for use in service creation (steps 28-30).

CREATE RESOURCE - MANUAL CREATION OF xNF RESOURCE

24. MANUAL CREATION, INTERNAL MODEL - The operator invokes the manual creation of a PNF or VNF resource. An internal VNF / PNF model is created with Metadata added.

25. INTERNAL DESCRIPTOR - In SDC, the internal descriptor properties are updated by the ONAP user.

26. LICENSE MODEL FILES - License model files can be added by the user in SDC.

27. ADDITIONAL ARTIFACTS - The operator may add additional artifacts to the resource (optional). The resource becomes available in the SDC catalog for use in service creation.  

4. Post Conditions

4a. Post Condition (Pre-onboarding)

...

• 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 - FrankfurtRead the Docs - for DCAE Designer: https://onap.readthedocs.io/en/latest/submodules/sdc.git/docs/dcaedesigner.html

SUPPORTING FILES & SLIDES