Table of Contents

1. Scope

DESCRIPTION: What do we mean by onboarding? A design time activity that brings "onboard" a resource into ONAP for later use in services. This flow describes the the onboarding of resources into SDC. This can apply to a new resource or an upgraded resource. A resource can be a VNF or PNF. Resources are onboarded into the SDC catalog during design time. This flow will describe what happens when a resource is brought into SDC. A resource in the SDC catalog can then be used in design time to define a service.

WHEN EXECUTED: During Design Time (before Run Time). When SDC Service imports a Resource into the SDC catalog.

PURPOSE: To bring in a VNF or PNF resource into SDC during design time.

INFORMATION PASSED: Vendor provided PNF onboarding package.

ACTORS:

• Service Designer
• Operations Specialist
• SDC (Deployment Studio)

For more information and exploration you can visit the Pre-Onboarding/Onboarding Wiki at: 5G - PNF Pre-Onboarding & Onboarding

OVERVIEW PNF ONBOARDING

 - Types on Onboarding: TOSCA Onboarding, HEAT Onboarding, Manual Onboarding #@#

 - Note: xNF applies only to VNF and PNF (not to ANF - Alloted network function)

Image Removed

Stage view for PNF pre-onboarding/onboarding

Image Removed

PACKAGE DELIVERY - A vendor delivers a package that is to be onboarded. Note: that if you use Manual onboarding in SDC you do not need to have a PNF package.

PRE-ONBOARDING - In VNF-SDK can validate the PNF package (optional).

ONBOARDING - SDC allows you to create a xNF resource without a PNF package (manual onboarding). Before services are created, SDC creates resources. You can (1) use HEAT template, or (2) use TOSCA template, or (3) use a SDC GUI to manually create a resource.

OVERVIEW VNF ONBOARDING

There are 4 options when onboarding for a VNF in R4/Dublin. The first method (SOL004 based VNF onboarding) is new in R4/Dublin, the other methods already exist since R1.

1 SOL004 BASED TOSCA METHOD OF VNF ONBOARDING:

This method of VNF onboarding uses the ETSI SOL004 package specification.

For VNFs, the VNF onboarding procedure should be the same as the PNF onboarding procedure (described above) except testing has not been done yet.

2 HEAT-TEMPLATE BASED VNF ONBOARDING:

In this method, the VNF is onboarded via a vendor-provided HEAT-based package (see diagram below).

The VNF associated artifacts can be added manually added after the VNF is created.

3 TOSCA-BASED VNF ONBOARDING:

In the TOSCA based VNF onboarding procedure the VNF is created from ONAP and adding TOSCA descriptor as an artifact.

Vendor provides package, do on-boarding procedure.

This is a non-ETSI way of onboarding.

In this case, the VNF package is similar to SOL004 but it doesn't have all the keywords.

4 MANUAL VSP ONBOARDING:

A VNF (resource) can also be manually onboarded by creating the VNF resource manually.

In this method, the VSP is created manually (import to VF module), manually create VF module.

A diagram showing the TOSCA method of VNF onboarding

A diagram showing the HEAT Template based method of VNF onboarding

2. Pre-Conditions

ONAP is ready:

• SDC - SDC is ready to ingest a package. Platform Information & Platform Data model are available.
• CERTIFICATION STUDIO - The Certification Studio has certified the Package ready for distribution (VNF-SDK)
• 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.

VENDOR deliveries received

• DESCRIPTOR - Vendor PNF or VNF Descriptor Defined
• VENDOR xNF PACKAGE - Vendor PNF or VNF Package with associated artifacts Delivered

2.1 xNF ONBOARDING PACKAGE

2.1.1 PNF PACKAGE

Vendors will prepare the Onboarding package (if you are not manually onboarding) The Onboarding Package Contains:

The following shows a diagram of the PNF Onboarding package which must be put together

Image Removed

2.1.2 VNF PACKAGE

Image Removed

Image Removed

A description of the things in the VNF and PNF Onboarding Packages SOL004 TOSCA-based Package (of the above diagrams).

• PNF DESCRIPTORS (PNFD) - (Instantiation/Design Time) PNFD and VNFD have been mapped to ONAP platform data/information model. That is, the onboarded descriptor models (vendor provided) have been mapped onto ONAP platform data & information models that are useable and known to ONAP. For a RAN PNF these are driven from the ETSI SOL001 standards.
• TOSCA METADATA - This file provided by the vendor describes the meta-information about the package. Notably it gives the directory location of key files in the package in the package as directory paths.
• MANIFEST FILE - The Manifest file include basic information about the package itself.
  • metadata with following keynames: pnfd_ provider, pnfd_name, pnfd_release_date_time, pnfd_archive_version
  • a list of all files contained in or referenced from the package with their location, expressed using a Source: location/name key-value pair. 
  • Non-mano-artifact tag: ONAP defined tags
• VES EVENT REGISTRATION - This file describes all of the VES events that are supported by the PNF. It defines the possible events that the PNF can support, such as faults, heartbeating, pnfRegistration, Performance measurements. These are defined in the VES Event specification document available in the repository. The Event Registration also defines all of the fields that each of these events have to fill in when they send the event, and the details of the VES header also.
• PM DICTIONARY - Performance Measurements and schema definitions. This is OPTIONAL, a PNF package does NOT necessarily have this artifact.
• ANSIBLE PLAYBOOKS - Ansible playbooks define the "scripts" that are used for remote Ansible communications from ONAP towards a PNF or VNF. This is OPTIONAL, a PNF or VNF package does NOT necessarily have this artifact.
• NETCONF YANG MODELS - Defines the NetConf Yang Models that are used for NetConf communications between ONAP and the PNF or VNF. This is OPTIONAL, a PNF or VNf package does NOT necessarily have this artifact. Starting in R3 (Casablanca release) and continuing into R4 (Dublin) a U/C w/ PNFs. VNFs available since R1.
• CHEF COOKBOOKS - When Chef communications are supported between ONAP and the PNF or VNF, these define the communication playbooks that are used by Chef. This is OPTIONAL, a PNF or VNF package does NOT necessarily have this artifact.
• MANUALS - Manuals can be included as informational artifacts in the VNF / PNF onboarding package provided by the vendor. These are typically additional information that can be provided (free-form) by the vendor. These are optional files and are not necessarily included in a package. They can be viewed by an ONAP operator in design time. This is OPTIONAL, a PNF package does NOT necessarily have this artifact.
• HELP FILES - Help files can be included as informational artifacts in the PNF onboarding package provided by the vendor. These kinds of file can provide information for trouble shooting for example, but can be any kind of assistance in text from the vendor. These are optional files and are not necessarily included in a package. They can be viewed by an ONAP operator in design time. This is OPTIONAL, a PNF package does NOT necessarily have this artifact.
• CUSTOMER DOCUMENTATION PRODUCTS - Customer documentation products can be included as informational artifacts in the PNF onboarding package provided by the vendor. These are optional files and are not necessarily included in a package. They can be viewed by an ONAP operator in design time. This is OPTIONAL, a PNF package does NOT necessarily have this artifact.
• TEST FILES - Test files are files that might be for testing, or end-to-end integration of the PNF with ONAP. These are optional files and are not necessarily included in a package. They can be viewed by an ONAP operator in design time. This is not included in R4/Dublin.
• LICENSING AGREEMENTS - Licensing agreements can be included as informational artifacts in the PNF onboarding package provided by the vendor. These are optional files and are not necessarily included in a package. They can be viewed by an ONAP operator in design time. This is not included in R4/Dublin and has been postponed.
• RESOURCE CONFIGURATION INFORMATION - Resource Configuration Information can be included in the PNF onboarding package provided by the vendor. For example, these might be settings or other configuration management type data associated with the resource. These are optional files and are not necessarily included in a package. They can be viewed by an ONAP operator in design time. This is OPTIONAL, a PNF package does NOT necessarily have this artifact. Note: starting in Frankfurt (R6) there is a CM (Config Mgmt) 5G U/C.
• CONTROLLER BLUEPRINT ARTIFACT - From a controller perspective, there is a TOSCA implementation to execute template for configuration. These include Velocity templates, Jinja template. They can be generic or per PNF type (customized). This is OPTIONAL, a PNF package does NOT necessarily have this artifact. In future releases this could be incorporated into the PNF package. In R4/Dublin a ONAP user would manually upload the Controller Blueprint Artifact.

2.2 EXAMPLE xNF PACKAGE w/ FILES & DIRECTORIES

This section describes what an example of what an actual package might look like. It shows some of the key files and directories and how they might be arranged and delivered.

The onboarding PNF/VNF Package must be defined as specified as ETSI SOL004 v2.6.1 + NFV CR NFVSOL(18)000746r3 

The package structure must be a CSAR with TOSCA-Metadata as specified in SOL004 section 4.1.2
The TOSCA.meta file keyname extension: SOL004 section 4.1.2.3. You can refer to the PNF Pre-onboarding & Onboarding Wiki for more information: 5G - PNF Pre-Onboarding & Onboarding

Image Removed

3. Information Flow

3.1 Pre-onboarding Flow

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

@startuml
participant VENDOR
participant ONAPUSER
participant VNFSDK
participant SDC
autonumber 

group PNF PACKAGE DELIVERY
	hnote over ONAPUSER : Vendor Package Delivery
	VENDOR -> ONAPUSER : VNF/PNF Package Delivery 	
end

group PRE-ONBOARDING
	hnote over VNFSDK : VNF SDK Package Validation (optional)
	ONAPUSER -> VNFSDK : PNF Package Delivery 
    VNFSDK -> VNFSDK : License File Check
	VNFSDK -> VNFSDK : Certificate File Check
	VNFSDK -> VNFSDK : Manifest file & destination cross-check
	VNFSDK -> VNFSDK : Manifest file tag Validation
	VNFSDK -> VNFSDK : TOSCA Metadata file validation
	hnote over VNFSDK : Certification Studio
	VNFSDK -> ONAPUSER : User checks validation
end

@enduml

3.2 Onboarding Flow

The following UML diagram shows Onboarding Flow:

@startuml
participant VENDOR
participant ONAPUSER
participant VNFSDK
participant SDC
autonumber 

group VNF/PNF PACKAGE DELIVERY
	hnote over ONAPUSER : Vendor Package Delivery
	VENDOR -> ONAPUSER : VNF/PNF Package Delivery 	
end

group PRE-ONBOARDING
	hnote over VNFSDK : Optional step
end

group Create a resource
hnote over SDC : Options to create a resource in SDC
group Onboarding
	hnote over SDC : Two onboarding options
	group Options
		group PACKAGE ONBOARDING
			hnote over SDC : Create a VSP model using onboarding package (PNF csar, VNF csar, or Heat)
			ONAPUSER -> SDC : onboarding a package
			SDC -> SDC : Create an internal model with Metadata added
 			SDC -> SDC : Transform onboarding artifacts into SDC onboarding
			SDC -> SDC : Transform onboarding descriptor into internal descriptor 
			SDC -> SDC : License Model Files Added
		end

		group Manual VNF VSP creation
			hnote over SDC : Manual create a VNF VSP model
			ONAPUSER -> SDC : Create a VSP
			SDC -> SDC : Create an internal model with Metadata added
			ONAPUSER -> SDC : Update internal descriptor proprieties 
			ONAPUSER -> SDC : License Model Files Added
			ONAPUSER -> SDC : Artifacts Added
		end
	end
end

group Create a resource
	group Create resource from a VSP
		hnote over SDC : Create resource model from a VSP
		ONAPUSER -> SDC : Create a VSP
		SDC -> SDC : Transform a VSP into a resource model
		SDC -> SDC : update internal descriptor proprieties 
		SDC -> SDC : update License Model Files
		ONAPUSER -> SDC : Additional Artifacts Added (Manual/Optional)
	end

	group Manual create a VNF or PNF resource
		hnote over SDC : Manual create a VNF / PNF Resources
		SDC -> SDC : create an internal VNF / PNF model with Metadata added
		ONAPUSER -> SDC : Update internal descriptor proprieties 
		ONAPUSER -> SDC : License Model Files Added
		ONAPUSER -> SDC : Additional Artifacts Added (Manual/Optional)
	end
end
end

group Create a Service
	hnote over SDC : Manual create a Service model
	SDC -> SDC : create an internal service model with Metadata added
	ONAPUSER -> SDC : Add Resource(s)
	ONAPUSER -> SDC : Additional Artifacts Added
end

@enduml

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

3.3 Flow Description: PNF PACKAGE DELIVERY

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 system or any other conceivable way to deliver digital information.

2. PNF PACKAGE DELIVERY – Package is accepted into ONAP

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

3.4 Flow Description: PACKAGE VALIDATION (VNF-SDK)

Image Removed

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

...

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 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) - Micro-Service or ONAP component 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/ONAP Component, A&AI, VES collector/DMaaP

For more information and details you can visit the RunTime DB Use Case Wiki at: CONFIGURATION PERSISTENCE SERVICE R6

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

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

SYNCING NEW xNF ADDED or DELETED (A&AI):

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

Image Added

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 Config 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 Config 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

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

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.

Image Added

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.

Image Added

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 CM Notify - Writing to RunTime DB

The following UML diagram shows the Information Flow for RunTimeDB

@startuml
participant PNF
participant VESCollector
participant DMaaP
participant RunTimeDB 
autonumber 

group RUNTIMEDB UPDATE
	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.3 Flow Description: mS Information Flow

1. VES Event – VES Event Received

A VES event (CM Notify) is received by the DCAE VES collector sent from the PNF.

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 Publishes on DMaaP with the CMNotify Topic

3. Subscription on DMaaP – RunTime Config DB gets the Notification

RunTime Config DB 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

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.

@startuml
participant AAI
participant DMaaP
participant RunTimeDB 
autonumber 

group RUNTIMEDB UPDATE
	hnote over AAI : xNF Update Notification
    AAI -> AAI : Detects xNF Update 	
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.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 from 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 A&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.

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 following UML diagram shows Where another ONAP component or Micro-Service updates the RunTimeDB

@startuml
participant ONAPComponent
participant DMaaP
participant RunTimeDB 
autonumber 

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

group Run Time DB Writing
	hnote over ONAPComponent : Notification
	ONAPComponent -> 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.

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

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

@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 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

SUPPORTING FILES & SLIDES

6. MANIFEST FILE TAG VALIDATION – 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 – 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 – The end user may then inspect that the PNF package has been appropriately verified in the Certification studio.

3.5 Flow Description: SDC PACKAGE ONBOARDING

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

Image Removed

A. UUID IDENTIFIER – SDC adds a UUID identifier.

...

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

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

PACKAGE ONBOARDING

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

In this case, a VSP model is created using an Onboarding package (PNF CSAR, VNF CSAR or Heat)

9. ONBOARD PACKAGE - The onboarding package is accessed by a Technology specialist/Asset manager

10. INTERNAL MODEL - An internal model is created in SDC with MetaData added.

11. TRANSFORM ARTIFACTS - The artifacts from the PNF or VNF package are transformed into onboarding artifacts during SDC onboarding.

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.  

CREATE A SERVICE

28. CREATE SERVICE - Create a internal service model with meta-data added. Additional restrictions to parameters may be given with customized types.

29. ADD RESOURCES - Resources can be added to the service by the user.

30. ADD ARTIFACTS - Other artifacts can be (optionally) added to the service by the user.

4. Post Condition

The post-conditions for the onboarding flow are:

• 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 are visible and loaded properly.
• PACKAGE VALIDATED - VNF-SDK has successfully validated the package and verified the content that VNF-SDK can perform validation on (See the VNF-SDK Validation section)
• ADDITIONAL ARTIFACTS - Additional manual artifacts can be incorporated into the Internal SDC xNF package.

REFERENCES

Read the Docs - for DCAE Designer: https://onap.readthedocs.io/en/latest/submodules/sdc.git/docs/dcaedesigner.html

SUPPORTING FILES & SLIDES