Page History

...

@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
	SO -> AAI : 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

1. 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. He 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. (Q: Catalog of Services at VID?)

   When you create a Service Model (you give it a human-friendly name) and a UUID is associated with the Service Model. Resources & how they are connected. When you instantiate a Service Model (service instances), they have names and UUIDs generated, you are using UUIDs. When you want an INSTANCE of a service model ONAP is using the UUIDs. There is a catalog of service models & list of service recipes that can be used. (1) Macro W/Fs. Recipes for service deploy (2) Al carte svcs, pic resource deploy manually (3) Macro GR flows use like building blocks to create recipes. Specific to the service (Generic) and GR (generic resource) flows, custom a la carte recipes. Select which recipes to use. Catalog available at VID termind, SDC makes this catalog available. Create it, distribute it, it should then appear in VID. List of service model, can search, button to “Deploy.

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)

5. SO/OOF: HOMING ASSIGNMENT – SO requests for a homing request to OOF for VNFs (and PNFs?). [Damian and I discussed what does homing mean for PNFs, this probably will see evolution from R5+]

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

7. << what >> – Flow description according to numbering. Include interface (e.g. SDCE-6) and main information  (can have a link to the information link).

8. ff

   SO/OOF: HOMING COMPLETION – OOF responds to the Homing request

   
   
   

@startuml
participant SO
participant NFVOrches
participant SDNC
participant OpenStack
autonumber 

group CLOUD RESOURCE REQUEST
	hnote over NFVOrches : Resources API
	hnote over SO : Resources Needed
	SO -> NFVOrches: Cloud Resources Request
	NFVOrches -> NFVOrches : Assign Cloud Resources
	hnote over NFVOrches: VM ID
	NFVOrches -> 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, Service ID
	SO -> OpenStack : Instantiation Request
	OpenStack -> OpenStack: VNF Instantiations
	OpenStack -> SO : Instantiation Response
end

@enduml

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

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

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

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

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

6. << what >> – Flow description according to numbering. Include interface (e.g. SDCE-6) and main information  (can have a link to the information link).

7. ff
8. ff

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

   
   
   

Continuation of SO Service Instantiation Flow:

...