2. Pre-Conditions

The preconditions are:

DESCRIPTORS - (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.
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 following diagram shows the SO Service Instantiation Flow:

PlantUML Macro

title	SDC SO Service DistributionInstantiation-1

@startuml
participant VIDCLIENT
participant SO
participant A&AIAAI
participant OOF
autonumber 

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

	VIDgroup INVENTORY RECORD CREATION
	hnote over AAI : AAI API
	SO -> SOAAI : ServiceInventory Record Creation Request
	note leftAAI -> AAI : Service Model ID, Service Recipe ID
Create Inventory Record
	hnote over AAI: INVENTORY RECORD
	AAI -> SO : Inventory Record Creation Response	
end

group INVENTORYHOMING RECORD CREATIONREQUEST
	hnote over A&AISO : xNF Resources, InventoryService CreationID
	SO -> OOF : Homing Assignment Request
	OOF -> OOF: Homing Assignment
	OOF -> SO : Homing Assignment Response
end

@enduml

SERVICE CREATION REQUEST

SERVICE CREATION REQUEST – User at the CLIENT or OSS requests for a Service instance to be created from the available services that could be instantiated. The user picks the service and finds the corresponding identifier. The user identifies the Service Model ID (what to deploy) and Service Recipe ID (how deploy). There is one Identifier per service that they wish to make an instance of. There is a catalog of available to Services that the user can select from in VID.
When the user wishes to create a Service Model, it is given a human-friendly name and a UUID is associated with the Service Model. Resources & how they are connected to the service are defined. When the user instantiates Service Model (service instances), they are given names and UUIDs are generated. When an INSTANCE of a service model is to be created, ONAP uses the UUIDs. There is a catalog of service models & list of service recipes that can be used. The user can select: (1) Macro Work-Flows and Recipes for service deploy, or (2) A la carte services: the user deploys resources manually or, (3) Macro Generic Resource flows which use "building blocks" to create recipes. The user can pick Specific Service (Generic) and GR (generic resource) flows, or custom a la carte recipes. The user Selects which recipes to use. There is a Catalog available at VID terminal and SDC makes this catalog available. The user can Create a service, distribute the service, and then it appears VID. The user sees a List of service model, he can search, and then Deploy.

CLIENT - The client that invokes this flow can be one of four types of clients. These components are described at this wiki: ARC Service Orchestrator Component Description - Dublin

VID - ONAP GUI
UUI - User Interface
CLI - Command Line Interface
External API / NBI - External API (North bound interface)

INFORMATION PASSED - The user inputs the Service Model ID and associated input parameters, and Service Recipe ID (the BPMN Workflow ID). The service recipe ID is distributed with the SDC Service CSAR package and is received by SO.

INVENTORY RECORD CREATION

2. SO/A&AI CREATES SERVICE RECORD – SO requests A&AI to create a Service record. SO requests A&AI to create records for the resources (VNFs, PNFs) associated with the service.

3.A&AI CREATES SERVICE RECORD – A&AI creates the Service Record.

4.SO/A&AI SERVICE CREATION RESPONSE – A&AI responds to SO with the create Service record completion and status (success/fail)

HOMING ASSIGNMENTS

5.SO/OOF: HOMING ASSIGNMENT – SO requests for a homing request to OOF for VNFs (and PNFs [Future]).

6. OOF: PERFORMS HOMING – OOF performs the Homing function. For VNFs, the concept of “homing” means assigning the VNF to the best “cloud” region to service that VNF, which subsumes the appropriate resources needed. For a PNF, the concept of “homing” would mean finding the best ONAP instance to serve the PNF. Event collection for VNF/PNF pick best DCAE instance and/or controller instance. OOF assigns the VNFs that are part of the service to appropriate cloud locations. OOF queries A&AI for a cloud instance that has the number and type of cloud resources needed and reserves them in A&AI. There may also be requirements imposed on a relationship between the VNF and PNF (for example latency requirements). OOF Work-flows that are related to homing. (link a wiki?). For example in a RAN (Wireless) network, the CU (VNF) may need to be within a certain latency (milliseconds) "away" from the DU (PNF) which might translate at layer-0 to some kilometers away (usually by backhaul fiber). OOF homing a ANF it reserves that resource.

7. SO/OOF: HOMING COMPLETION – OOF responds to the Homing request with the homing assignments.

PlantUML Macro

title	SO Service Instantiation-2

@startuml
participant SO
participant MultiCloud
participant SDNC
participant OpenStack
 
autonumber 8

group CLOUD RESOURCE REQUEST
	hnote over MultiCloud : Inventory Record Creation Resources API
	hnote over SO : Resources Needed
	SO -> MultiCloud : Cloud Resources Request
	note left: Service ModelMultiCloud -> MultiCloud : Assign Cloud Resources
	hnote over MultiCloud: VM ID
	MultiCloud -> SO : Cloud Resources Response
end

group HOMINGNETWORK ASSIGNMENTS
	hnote over SO : SO API
	SO -> SDNC : Network Assignment Request
	SDNC -> SDNC : Perform Network Assignments
	hnote over SDNC: AAI Update
	SDNC -> SO : Network Assignments Response	
end

group INSTANTIATION REQUEST
	hnote over OOFSO : Homing xNF Resources, VFM ID
	SO -> OpenStack : Instantiation Request
	OpenStack -> OpenStack: VNF#1 Instantiations
	OpenStack -> OpenStack: VNF#n Instantiations
	OpenStack -> SO : Instantiation Response
end

@enduml

RESOURCE REQUESTS

8. SO/OPENSTACK: CLOUD RESOURCE REQUEST – SO requests Openstack (Blazer) with a cloud resources request to OOF. OOF performs the NVF Orchestration. Does OOF do this? Is this not done? MEC instances.

9. OPENSTACK: ASSIGN CLOUD RESOURCES – Openstack Blazer assigns cloud resources based on the needs of the service. Assignments are balanced against NFV compute resources in each region, what is currently used/reserved and total capability. Compute resources availability to deploy a VM are consider. The NFV-Orchestration is defined in ETSI NFV. SO can trigger a reservation request. NFV orchestration can create instances of different types. NFV orchestration has a policy. OpenStack Blazer, reservations localized to the cloud instance. SO > Multi-Cloud performs the Resource assignments. SO does not call Openstack directly. A resource is something that can't just sprawl everywhere. When ONAP is homing it is looking a home for a resource (a cloud instance). Geo-diversity is not yet modeled. ANF. MCloud: Translates generic requirements of resources into VIM-specific APIs to get that resource.

10. SO/OPENSTACK: CLOUD RESOURCE RESPONSE – Openstack responds with the allocated resources.

NETWORK ASSIGNMENTS

11. SO/SDN-C NETWORK ASSIGNMENTS – SO requests SDN-C to perform the Network Assignments needed by the Service instance. Can a Subnet, Network Port be assigned? (Virtual MAC, IP address), connect to VM. VM > create port > connect to VM.

12. SDN-C NETWORK ASSIGNMENTS – SDN-C performs Network Assignments needed by the Service instance.

13. SO/SDN-C NETWORK ASSIGNMENTS – SDN-C responds to SO with the Network Assignments needed by the Service instance and the status (success/fail).

INSTANTIATION REQUEST

14. SO/MCLOUD INSTANTIATION REQUEST – SO requests M-Cloud to perform the VNF instantiations needed by the Service instance.

15. MCLOUD INSTANTIATION REQUEST (VNF#1 ...) – MCloud performs VNF instantiations. There might be "multiple" of these VNF Instantiations depending on the number of VNF resources associated with the service. VNF-Adaptor is used.

16. MCLOUD INSTANTIATION REQUEST (... VNF #n) – MCloud performs VNF instantiations for as many VNFs are there are. Step #15 is repeated for as many VNFs as are needed for the service..

17. SO/MCLOUD INSTANTIATION RESPONSE – MCloud responds to SO with the VNF instantiations needed by the Service instance and the status (success/fail)

Continuation of SO Service Instantiation Flow:

PlantUML Macro

title	SO Service Instantiation-3

@startuml

participant VID
participant SO
participant Controller

autonumber 18

group ASSOCIATED RESOURCES FOR VNFs
	hnote over SO : Service Creation Request
	note left Instance ID, Configuration information
 	SO -> AAI : Associated Resource Created
end

group ASSOCIATED RESOURCES FOR PNFS
	hnote over SO : Service ModelInstance ID, Configuration information
 Service Recipe ID
	
end

@enduml

...

	SO -> AAI : Associated Resource Created
end

group CONFIGURE & ACTIVATE SERVICE
	hnote over Controller : Service Instance ID, Configuration information
	SO -> Controller : Activate Service
	Controller -> Controller : Configure Associated Resources
	Controller -> Controller : A&AI Updates
	Controller -> Controller : DCAE Monitoring Activated
	Controller -> Controller : Activate Service (State)
	Controller -> SO : Service Activated	
end

group USER RESPONSE
	hnote over SO : Service Instance UUID
	SO -> VID : Service Creation Response, Inform User
end

@enduml

ASSOCIATE RESOURCE WITH SERVICE

18. ASSOCIATE RESOURCES WITH SERVICE – A la carte Create resource. Macro W/F needs service instance ID associate resource w/ Service Instance. When instantiate PNF service (PNF name) subscribe ID. Update instance in A&AI. Create a relation object where service instance ID & PNF instance ID. Relation modeled service instance + resources. Resource and can see which services it is used. VNFs create service have UUID of service instance. At creation of VNF create the Instance object.

https://wiki.onap.org/display/DW/VNF+and+PNF+Building+Block+Strategy

CPE, BBS, starts when you startup the PNF. Cloud environment creates a VNF. Registered/discovered PNF, build a homing service PNF. How will this work w/ 5G RAN. BBS U/C, registering the Box, customer starting up the box. Waiting for registration event. When receive the registration configure the network, additionalfield has domain-specific information to calculate best configuration of network to configure the PNF. After homing, SO creates a resource level sub-flow w/ a globally unique UUID in A&AI. In that that in sub-flow there is a correlation done with VES. The configuration that takes place happen in the resource level sub-flows. Svc instantion, correlation ID in A&AI. VES w/ correlation ID SO does the correlation (Plug n Plug).

ACTIVATE RESOURCES

19. SO/CONTROLLER: ACTIVATE SERVICE REQUEST – SO requests the controller (SDN-C, SDN-R, VF-C, APP-C) to activate the service. (Where does SO get data to configure a service??). SO determines the order in which to instantiate the xNF resources. Right now SO does networks first then VNFs. Eventually this should be model-driven from TOSCA. Heirarchical resource creation & nested services.

20. CONTROLLER: ACTIVATE xNF – The controller (SDN-C, SDN-R, VF-C, APP-C) to activate the xNF resources associated with the service.

21. CONTROLLER: CONFIGURE xNF – The controller configures the service, and configures the associated xNF resources associated with the service.

22. A&AI Published to DMaaP - A&AI publishes on DMaaP that a new service is active, How does it know? A change in status? #1 when dealing with VNFs, the contents of A&AI created when doing something in VID. Create a VNF in a service. Record in A&AI is created immediately. (no VMs are deployed). Same for VF modules. Get back info from OpenStack, HEAT. States are then updated. #2 BBS event CPEauthenticated. BBS & Service, send registration w/ SO & Controller configure networking. Sending CPE authenticated (event means running, active, successfully configured). Go to service instance mark it as “activated”. Confirm end-user can use the services. W/F specific to services. Refer to generic building blocks. TOSCA Modeling of nodes. TOSCA orchestrator has plug-ins for clouds. Cloud specific parameters, unable to create a node in AWS/Azure. A&AI can be configured to “announce” a state change of a service.

23. DCAE LISTENING - DCAE is listening for a new service notifications and starts to monitor the service.

24. SO/CONTROLLER: ACTIVATE SERVICE RESPONSE – The controller responds with the Service configuration, and responds to the activation service request back to SO.

25. SO/A&AI UPDATE RECORDS – SO updates the appropriate A&AI records with activation information.

USER NOTIFIED

26. USER NOTIFIED - SO notifies service initiator that the service is active. In this example flow, it would be the user at the VID who gets informed that the Service is available and active.

4. Post Condition

The post-conditions are:

A&AI RECORD - Service has an A&AI Service Record Entry.
RESOURCES INSTANTIATED - Resources associated with the Service have been successfully given network assignmentsinstantiated.
CLOUD RESOURCES - Cloud resources have been successfully assigned necessary to support the service
NETWORK ASSIGNMENTS - Network assignments have been assigned for the service
SECURITY - Security assignments have been successfully performed (IAK, RV, CA root cert, CA URL)
VNF INSTANTIATION - VNF instantiations have been successfully performed
CONFIGURATIONS - Configurations from Controller to xNFs have been successfully performed.

...

<<interface name (e.g. SDCE-6) >> https://wiki.onap.org/display/DW/SDC+Distribution+client+AID
<< models >> <<link>>

Space shortcuts

Page tree

Versions Compared

Old Version 13

New Version Current

Key

2. Pre-Conditions

SERVICE CREATION REQUEST

INVENTORY RECORD CREATION

HOMING ASSIGNMENTS

RESOURCE REQUESTS

NETWORK ASSIGNMENTS

INSTANTIATION REQUEST

ASSOCIATE RESOURCE WITH SERVICE

ACTIVATE RESOURCES

USER NOTIFIED

4. Post Condition

Space shortcuts

Page tree

Page History

Versions Compared

Old Version 13

New Version Current

Key

2. Pre-Conditions

SERVICE CREATION REQUEST

INVENTORY RECORD CREATION

HOMING ASSIGNMENTS

RESOURCE REQUESTS

NETWORK ASSIGNMENTS

INSTANTIATION REQUEST

ASSOCIATE RESOURCE WITH SERVICE

ACTIVATE RESOURCES

USER NOTIFIED

4. Post Condition