...
The following diagram shows the SO Service Instantiation Flow:
PlantUML Macro | ||
---|---|---|
| ||
@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 – User at the VID 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.
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.
A&AI CREATES SERVICE RECORD – A&AI creates the Service Record.
SO/A&AI SERVICE CREATION RESPONSE – A&AI responds to SO with the create Service record completion and status (success/fail)
SO/OOF: HOMING ASSIGNMENT – SO requests for a homing request to OOF for VNFs (and PNFs [Future]).
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.
SO/OOF: HOMING COMPLETION – OOF responds to the Homing request with the homing assignments.
PlantUML Macro | ||
---|---|---|
| ||
@startuml participant SO participant MultiCloud participant SDNC participant OpenStack autonumber group CLOUD RESOURCE REQUEST hnote over MultiCloud : Resources API hnote over SO : Resources Needed SO -> MultiCloud : Cloud Resources Request MultiCloud -> MultiCloud : Assign Cloud Resources hnote over MultiCloud: VM ID MultiCloud -> SO : Cloud Resources Response end group NETWORK ASSIGNMENTS hnote over SO : SO API SO -> SDNC : Network Assignment Request SDNC -> SDNC : Perform Network Assignments hnote over SDNC: AAI Update SO -> SDNC : Network Assignments Response end group INSTANTIATION REQUEST hnote over SO : xNF Resources, ServiceVFM ID SO -> OpenStack : Instantiation Request OpenStack -> OpenStack: VNF VNF#1 Instantiations OpenStack -> OpenStack: VNF#n Instantiations OpenStack -> SO : Instantiation Response end @enduml |
...
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.
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.
SO/OPENSTACK: CLOUD RESOURCE RESPONSE – Openstack responds with the allocated resources.
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.
SDN-C NETWORK ASSIGNMENTS – SDN-C performs Network Assignments needed by the Service instance.
SO/SDN-C NETWORK ASSIGNMENTS – SDN-C responds to SO with the Network Assignments needed by the Service instance and the status (success/fail).
SO/MCLOUD INSTANTIATION REQUEST – SO requests M-Cloud to perform the VNF instantiations needed by the Service instance.
MCLOUD INSTANTIATION REQUEST – 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.
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 | ||
---|---|---|
| ||
@startuml participant VID participant SO participant Controller autonumber group ASSOCIATED RESOURCES hnote over SO : Service Instance ID, Configuration information SO -> SO : 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 |
...