...

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

@startuml
participant SDC
participant SO
participant DCAE
participant AAI
Participant SDNC
Participant APPC
Participant CLAMP
Participant POLICY
Participant MC

autonumber 

== Register to Service CSAR Distribution == 

SO-->SO: Register for Distribution

note right: performed by all recipients of the CSAR

== Service CSAR Distribution == 


group Distribute to SO
	hnote over SO : SO Listener
	SDC -> SO : SDC Distribution Notification
	note left: Using DMaaP
	SO -> SDC : Request Artifact (Artifact Type)
	SDC ->SO: Respond with Artifact 
	SO --> SO : Store CSAR
	SO -> SDC: Distribution Status Update
end


group Distribute to DCAE
 	hnote over DCAE : Service Change Handler 
	
	SDC -> DCAE : SDC Distribution Notification
 	note left: Using DMaaP
	DCAE -> SDC : Request Artifact (Artifact Type)
	SDC -> DCAE: Respond with Artifact 
	DCAE --> DCAE : Store CSAR
	DCAE -> SDC: Distribution Status Update
end

group Distribute to AAI
	hnote over AAI: AAI Listener
	SDC -> AAI : SDC Distribution Notification
 	note left: Using DMaaP
 	AAI -> SDC : Request Artifact (Artifact Type)
	SDC -> AAI : Respond with Artifact 
	AAI --> AAI : Store CSAR
	AAI -> SDC: Distribution Status Update
end

group Distribute to SDNC
 	hnote over SDNC: UEB Listener
	SDC -> SDNC : SDC Distribution Notification
 	note left: Using DMaaP
 	SDNC -> SDC : Request Artifact (Artifact Type)
	SDC -> SDNC : Respond with Artifact 
	SDNC --> SDNC : Store CSAR
	SDNC -> SDC: Distribution Status Update
end


group Distribute to APPC  	
	hnote over APPC: Listener
  	SDC -> APPC : SDC Distribution Notification
 	note left: Using DMaaP
 	APPC -> SDC : Request Artifact (Artifact Type)
	SDC -> APPC : Respond with Artifact 
	APPC --> APPC : Store CSAR
	APPC -> SDC: Distribution Status Update
end


group Distribute to CLAMP
	hnote over CLAMP: Listener

	SDC -> CLAMP : SDC Distribution Notification
 	note left: Using DMaaP
 	CLAMP -> SDC : Request Artifact (Artifact Type)
	SDC -> CLAMP : Respond with Artifact 
	CLAMP --> CLAMP : Store CSAR
	CLAMP -> SDC: Distribution Status Update

end 

group Distribute to POLICY
	hnote over POLICY: Listener

	SDC -> POLICY : SDC Distribution Notification
 	note left: Using DMaaP
 	SDC <- POLICY : Request Artifact (Artifact Type)
	SDC -> POLICY : Respond with Artifact 
	POLICY --> POLICY : Store CSAR
	POLICY -> SDC: Distribution Status Update

end

group Distribute to MultiCloud
	hnote over MC: Listener
 	SDC -> MC : SDC Distribution Notification
 	note left: Using DMaaP
 	MC -> SDC : Request Artifact (Artifact Type)
	SDC -> MC : Respond with Artifact 
	MC --> MC : Store CSAR
	MC -> SDC: Distribution Status Update
end 



== Un-Register to Service CSAR Distribution (optional, at any time) == 
SO-->SO: Un-Register for Distribution
note right: performed by all recipients of the CSAR that want to un-register


@enduml

The following text describes each of the steps in the above flow. More details and exceptions can be described in the detailed descriptions. Wiki page links can also be linked for a reader to explore more.

1. REGISTER FOR DISTRIBUTION – SO, DCAE, A&AI, SDN-C, APP-C, VF-C register for distribution of the SDC Artifact distribution via the registration service of the SDCE-6 interface. This is performed by all recipients of the CSAR. This allows the ONAP platform component to receive the message which will contain the package later on.

2. SDC DISTRIBUTION NOTIFICATION (with SO) – SDC Distributes to service CSAR SO using the SDCE-6 interface. The SO listener retrieves the SDC CSAR package. SDC distributes the Service Distribution CSAR package which includes all of the artifacts, templates and resources related to the service created in design time. SDC publishes a topic onto DMaaP. Any RT component that has subscribed to that topic can get that package.

3. REQUEST ARTIFACT - The ONAP platform component can request for the artifacts required by the component.
4. RESPOND WITH ARTIFACT - The artifacts or SDC CSAR Package is retrieved from the DMaaP Bus. SDC responds with the package.

5. STORE CSAR PACKAGE – SO stores the distributed package.

6. DISTRIBUTION STATUS UPDATE (with SO) - SO responds to the SDC Distribution exchange using SDCE-6.
7. SDC DISTRIBUTION NOTIFICATION (with DCAE) - SDC Distributes service CSAR to DCAE using the SDCE-6 interface,  the DCAE Service Change Handler retrieves the SDC CSAR package, SDC distributes the Service Distribution CSAR package which includes

The Onboarding Package:

2. Pre-Conditions

Vendors will prepare the Onboarding package:

• MODELS IN SDC - SDC contains the verified service and resource descriptor (models). These resource descriptors are provided by the vendor (PNFD and VNFD).
• xNFs ONBOARDED - Associated resources (PNF, VNF, ANF) used by services have been properly onboarded.
• SERVICE DEFINED - Services have been defined in design time, and associated templates, control loops, blueprints have been incorporated into the service CSAR package.
• SERVICE CSAR PACKAGE - SDC has composed the Service Design CSAR package ready for distribution.
• CERTIFICATION STUDIO - The Certification Studio has certified the Package ready for distribution
• DEPLOYMENT STUDIO - The Deployment Studio operator has identified the Service Design CSAR package for distribution.
• SOFTWARE - Software images loaded in OpenStack installation, where instantiation will happen (since no S/W image repository). Need to be available in Target Cloud Instances.
• USER & CATALOG - The User at OSS or VID has knowledge of the Service Model Identifier that they wish to create a service instance of. The Service is seen as available in the catalog.

The Onboarding Package Contains:

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

Image Added

A description of the things in the PNF Onboarding Package

• 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.
• TOSCA METADATA - This file provided by the vendor describes the meta-information about the package. Notably it gives the key files in the package and their locations in the package as directory paths.
• MANIFEST FILE - The Manifest file include basic information about the package itself.
• VES EVENT REGISTRATION - This file describes all of the events that are supported by the PNF. It defines the possible events that the PNF can support, such as faults, heartbeating, 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 also
• PM DICTIONARY - Performance Measurements definitions.
• ANSIBLE PLAYBOOKS - Ansible playbooks define the "scripts" that are used for remote ansible communications from ONAP towards a PNF.
• NETCONF YANG MODELS - Defines the NetConf Yang Models that are used for NetConf communications between ONAP and the PNF.
• CHEF COOKBOOKS - When Chef communications are supported between ONAP and the PNF, these define the communication playbooks that are used by Chef
• MANUALS - Manuals 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.
• HELP FILES - Help files 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.
• 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.
• TEST FILES - Manuals 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.
• 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.
• RESOURCE CONFIGURATION INFORMATION - Resource Configuration Information can be included 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.

3. Information Flow

The following diagram shows the SO Service Instantiation Flow:

@startuml
participant VID
participant SO
participant AAI
participant OOF
autonumber 

group SERVICE CREATION REQUEST
	hnote over SO : SO/VID API
	hnote over VID : Svc Model ID, Recipe ID
	VID -> SO : Service Creation Request	
end

group INVENTORY RECORD CREATION
	hnote over AAI : AAI API
	SO -> AAI : Inventory Record Creation Request
	AAI -> AAI : Create Inventory Record
	hnote over AAI: INVENTORY RECORD
	AAI -> SO : Inventory Record Creation Response	
end

group HOMING REQUEST
	hnote over SO : xNF Resources, Service ID
	SO -> OOF : Homing Assignment Request
	OOF -> OOF: Homing Assignment
	OOF -> SO : Homing Assignment Response
end

@enduml

SERVICE CREATION REQUEST

...