Page History

...

1. SO → OOF - Get Target <Cloud Owner, Cloud Region> for the Service Instances

2. OOF → Policy - Fetch Enhanced Capacity Check & Cloud Selection Policy for

...

Homing

2a) OOF Processing - the fetched Policy is stored in a local data structure and is available for further use (need OOF code changes).

Code Block

language	py
theme	Emacs
title	OOF Homing Enhanced Capacity Check & Cloud Selection Policy Example
linenumbers	true
collapse	true

{

"service": "cloudSelectionPolicy",
"policyName": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vCPE_VNF",
"description": "Cloud Selection Policy for vCPE VNFs",
"templateVersion": "0.0.1",
"version": "oofMulti-cloudCasablanca",
"priority": "3",
"riskType": "test",
"riskLevel": "2",
"guard": "False",

"content": 
{
	{
		"cloudOwner": "All", //can be a specific cloud owner such as Azure, VMware VIO, Wind River Titanium Cloud etc.
		"cloudRegion": "All", //can be a specific cloud region for a cloud owner
		"capacityCheck": "TRUE", //perform capacity check per <cloud owner, cloud region>
		"dollarCostEvaluationVM-Type": "TRUE", //evaluate dollar cost per VM type if operator has configured a policy
		"dollarCostEvaluationVM-FeatureGroup": "TRUE" //evaluate dollar per feature/group of features if operator has configured a policy
	},		 			  	
}

"resources": ["vgw", "vgmux"], //"vgw" is also interchangeably used as "vg"
"applicableResources": "any",
"identity": "cloud-atrributes",
"policyScope": ["vCPE", "US", "INTERNATIONAL", "ip", "vgw", "vgmux"],
"policyType": "AllPolicy"

}

...

3a) OOF Processing - Perform Cloud Agnostic Capability check for each <cloud owner, cloud region>

4. OOF → MC - Push Cloud Agnostic Policy for the Service Instance - perform Cloud Specific Check (capability/capacity/cost metrics) for each registered Cloud Region in Multi-

...

Cloud

4a) OOF Processing

The enhanced OOF ↔ MC capacity check API, described below, is filled based on the enhanced Capacity Check & Cloud Selection Policy for Homing retrieved in step 2) – need OOF code changes.

Code Block

language	py
theme	Emacs
title	OOF <-> MC API Examples
linenumbers	true
collapse	true

//flexibility of having cloud owner and region in the new API provides fine grained control, addresses capacity/cost differences across different //cloud owners/regions and ensures backward compatibility

OOF -> MC
{
	"VNFC": "vgw", //"vgw" is also intechangeably used as "vg" //new in R3

	{   //new in R3
		"cloudOwner": "All", //can be a specific cloud owner such as Azure, VMware VIO, Wind River Titanium Cloud etc. 
		"cloudRegion": "All", //can be a specific cloud region for a cloud owner
		"dollarCostEvaluationVM-Type": "TRUE", //evaluate dollar cost per VM type if operator has configured a policy
		"dollarCostEvaluationVM-FeatureGroup": "TRUE" //evaluate dollar per feature/group of features if operator has configured a policy
	},			 			  	
  		
	{
		"cloudOwner": "OpenStack", 	// new in R3, 
								   	// different cloud owners may need different capacities for the same VNFC because of implementation differences
		"cloudRegion": "All", 		// new in R3, 
							 		// different cloud regions for a cloud owner may need different capacities for the same VNFC due to different SW
							 		// versions and HW configuration	

		"capacityProperty": //same as R2, presence of this means capacity check needs to be done for the <cloud owner, cloud region>
		{ 		 		
			"request": 
				"{\"vCPU\": {\"quantity\": {\"get_param\": \"REQUIRED_VCPU\"}, \"Memory\": {\"quantity\": {\"get_param\": \"REQUIRED_MEM\"}, 	
				\"unit\": 	\"GB\"}, \"Storage\": {\"quantity\": {\"get_param\": \"REQUIRED_DISK\"}, \"unit\": \"GB\"}}"
		}		
	},
}

//return netValue per <cloud owner, cloud region>
//cloud regions which fail capacity check are not in this list
MC -> OOF
{
	{
		"cloudOwner": "OpenStack",
		"cloudRegion": "1",
		"netValue": "99"
	},
	{
		"cloudOwner": "VIO",
		"cloudRegion": "5",
		"netValue": "100"
	},
	{
		"cloudOwner": "Azure",
		"cloudRegion": "3",
		"netValue": "101"
	},
}

5a) MC Processing (need MC code changes)

For each cloud owner

Instance Type Handling
- Instance Type is passed in the capacity check API from OOF (Discuss) //Note, SO → MC passes OpenStack flavor name in the Heat Template/Env file
- Convert to appropriate instance type based on intent //e.g. "Infrastructure Resource Isolation for VNF" may result in a different instance type if the cloud owner supports "Burstable QoS"
Parse OOF → MC Policy API
For each cloud region // Public cloud could have different costs in different geographic locations
- net_value_cost = net_value_cost + cost_instance_type // cost per instance type is based on policy (for R3, it is picked up from Multi Cloud configuration file)
- net_value_cost = net_value_cost + cost_intent //e.g. "Infrastructure High Availability (HA) for VNF" may have additional cost
- Capacity Check
  - Private Clouds (OpenStack based)
    - Perform capacity check per specified Tenant (OpenStack Project)
    - If Capacity check fails, drop the cloud region out of the candidate list
  - Public Clouds or Other Clouds
    - Capacity check always succeeds //assumption: public cloud has infinite capacity

5. MC → OOF – Return a net value cost for each <cloud owner, cloud region> if the capacity check succeeds

6. OOF → SO - Return the target <cloud owner, cloud region> for the Service Instance

7. SO → MC - Deploy VNF template in the target <cloud owner, cloud region> for the Service Instance (need code changes)

OOF->MC Processing

MC Inter-Cloud Placement (aka Homing) Policy

6a) OOF Processing - Multi-objective Optimization (need OOF code changes)

Each service specifies an service-specific objective function that is stored as part of the service-specific policy and is used by OOF to evaluate the candidate <cloud owner, cloud region>. For simplicity of the example, let’s consider service that consists only of one VNF instance. The objective function has two components:

- distance from customer location to the VNF - the service designed assigns a weight for the distance: wd

- the cost of deploying the VNF in a location - the service designer assigns a weight for the cost: wc

OOF optimizes function: min (wd*distance + wc*cloud_net_value)

If the service does not care about the cost at all, it would set wc = 0. If the service designer wants to minimize cost, he could set wd=0. Note that candidates that are too far can be eliminated by a distance constraint even before the optimization. For example, if the service has a distance constraint of at most 100 kilometers, then only those <cloud owner, cloud region> within 100 kilometers to the customer location would be considered in the objective function evaluation.

If the service designer wants to trade off between distance and cost, for example, they might set wd = 1, wc = 2. This would mean that one $1 increase in price is as valuable as 2 kilometers in distance.

<cloud owner, cloud region> Candidate 1: $100, 100 kilometers => value: 300

<cloud owner, cloud region> Candidate 2: $150, 80 kilometers => value: 380

<cloud owner, cloud region> Candidate 3: $50, 190 kilometers => value: 290 <- pick this one

6. OOF → SO - Return the target <cloud owner, cloud region> for the Service Instance

7. SO → MC - Deploy VNF template in the target <cloud owner, cloud region> for the Service Instance

MC Processing (need MC code changes)

MC Inter-Cloud Placement (aka Homing) Policy

Code Block

language	py
theme	Emacs
title	MC Inter-Cloud Placement (aka Homing) Policy
linenumbers	true
collapse	true

Code Block

language	py
theme	Emacs
title	MC Inter-Cloud Placement (aka Homing) Policy
linenumbers	true
collapse	true

		"intent": 
		{
			"name": "Infrastructure High Availability (HA) for VNF", 
				//realization thru OpenStack-based: anti-affinity, Azure: Fault Domain or
    			//Different anti-affinity models from ETSI -- host-level, rack-level, availability zone level
				//max-count in heat template - scale out factor
				//server-group in heat template - usable thru API and CLI in OpenStack, VMware VIO
		}
		"intent": 
		{
			"name": "Infrastructure High ResourceAvailability Isolation(HA) for VNF", 
				// realization possible without dedicating CPU and Memory, refer to section on "Cloud Resource Partitioning for Differentiated QoS" 
	realization thru OpenStack-based: anti-affinity, Azure: Fault Domain or
    			//Different onanti-affinity howmodels thisfrom canETSI help in offering tiered services
			"qosProperty": 
			{-- host-level, rack-level, availability zone level
				{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}//max-count in heat template - scale out factor
				//{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}, {"operator", "OR"}, {"Guaranteed QoS": "TRUE"}server-group in heat template - usable thru API and CLI in OpenStack, VMware VIO
		}
		"intent": 
		{
			"name": "Infrastructure Resource Isolation for VNF", 
				// VMwarerealization VIOpossible -without tenantdedicating VDC CLICPU and APIMemory, -refer configureto thesection appropriate settings per tenant
				// Burstable QoS is specified through min guarantee (part of flavor metadata -- 
              	// https://docs.openstack.org/horizon/latest/admin/manage-flavors.html
			}
		}

SO Processing

Same as R2

SO → MC API

Same as R2

SO → MC Processing

MC Workload Deployment Policy

on "Cloud Resource Partitioning for Differentiated QoS" 
				// on how this can help in offering tiered services
			"qosProperty": 
			{
				{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}
				//{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}, {"operator", "OR"}, {"Guaranteed QoS": "TRUE"}
				// VMware VIO - tenant VDC CLI and API - configure the appropriate settings per tenant
				// Burstable QoS is specified through min guarantee (part of flavor metadata -- 
              	// https://docs.openstack.org/horizon/latest/admin/manage-flavors.html
			}
		}

SO Processing

Same as R2

SO → MC API

Same as R2

SO → MC Processing

MC Workload Deployment Policy

Code Block

language	py
theme	Emacs
title	MC Workload Deployment Policy
linenumbers	true
collapse	true

Code Block

language	py
theme	Emacs
title	MC Workload Deployment Policy
linenumbers	true
collapse	true

		"intent": 
		{
			"name": "Infrastructure High Availability (HA) for VNF", 
				//realization thru OpenStack-based: anti-affinity, Azure: Fault Domain or
    			//Different anti-affinity models from ETSI -- host-level, rack-level, availability zone level
				//max-count in heat template - scale out factor
				//server-group in heat template - usable thru API and CLI in OpenStack, VMware VIO
		}
		"intent": 
		{
			"name": "Infrastructure High ResourceAvailability Isolation(HA) for VNF", 
				// realization possible without dedicating CPU and Memory, refer to section on "Cloud Resource Partitioning for Differentiated QoS" 
				// on how this can help in offering tiered services
			"qosProperty": 
			{
				{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}thru OpenStack-based: anti-affinity, Azure: Fault Domain or
    			//Different anti-affinity models from ETSI -- host-level, rack-level, availability zone level
				//max-count in heat template - scale out factor
				//{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}, {"operator", "OR"}, {"Guaranteed QoS": "TRUE"}
				// VMware VIO - tenant VDC CLI and API - configure the appropriate settings per tenantserver-group in heat template - usable thru API and CLI in OpenStack, VMware VIO
		}
		"intent": 
		{
			"name": "Infrastructure Resource Isolation for VNF", 
				// Burstablerealization QoSpossible iswithout specifieddedicating throughCPU minand guaranteeMemory, (partrefer ofto flavorsection metadataon --"Cloud 
Resource Partitioning for Differentiated QoS" 
				// on how this can help in offering tiered 	// https://docs.openstack.org/horizon/latest/admin/manage-flavors.htmlservices
			"qosProperty": 
			}{
		}

OOF → Multi-VIM/Cloud Policy API - Other

...

				{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}
				//{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}, {"operator", "OR"}, {"Guaranteed QoS": "TRUE"}
				// VMware VIO - tenant VDC CLI and API - configure the appropriate settings per tenant
				// Burstable QoS is specified through min guarantee (part of flavor metadata -- 
              	// https://docs.openstack.org/horizon/latest/admin/manage-flavors.html
			}
		}

OOF → Multi-VIM/Cloud Policy API - Other

Convert to appropriate instance type based on intent //e.g. "Infrastructure Resource Isolation for VNF" may result in a different instance type if the cloud owner supports "Burstable QoS"
- Example
  - VNFC with "Guaranteed QoS"
    - vCPU (Min/Max) - 16, Mem (Min/Max) - 32GB
  - Same VNFC with "Burstable QoS", 25% oversubscription
    - vCPU (Min) - 16, Mem (Min) - 32GB
    - vCPU (Max) - 20, Mem (Max) - 40GB

SO → Multi-VIM/Cloud

Get Cloud Region of interest
Parse Template (e.g. OpenStack Heat Template)
- For each VNFC, instance type in the template
  - Get Policy based on <VNFC, Cloud Owner>
    - Value/Content: <Policy JSON - only Intent portion>
  - Parse Policy JSON
  - Modify template according to Intent - intent examples below
    - "Infrastructure High Availability (HA) for VNF"
    - "Infrastructure Resource Isolation for VNF"
      - "Burstable QoS"

Policy Management

Store VNFC Policy in Multi-Cloud as a Configuration file
- Policy file naming: <VNFC (e.g. vGMux), Cloud Owner>
- Content:
  - <Policy JSON - only Intent portion>
  - InstanceType

...

vCPU (Min/Max) - 16, Mem (Min/Max) - 32GB

...

SO → Multi-VIM/Cloud

Get Cloud Region of interest
Parse Template (e.g. OpenStack Heat Template)
- For each VNFC, instance type in the template
  - Get Policy based on <VNFC, Cloud Owner>
    - Value/Content: <Policy JSON - only Intent portion>
  - Parse Policy JSON
  - Modify template according to Intent - intent examples below
    - "Infrastructure High Availability (HA) for VNF"
    - "Infrastructure Resource Isolation for VNF"
      - "Burstable QoS"

Policy Management

Store VNFC Policy in Multi-Cloud as a Configuration file
- Policy file naming: <VNFC (e.g. vGMux), Cloud Owner>
- Content:
  - <Policy JSON - only Intent portion>
  - InstanceType

Optimization

Each service specifies an service-specific objective function that is stored as part of the service-specific policy and is used by OOF to evaluate the candidates. For simplicity of the example, let’s consider service that consists only of one VNF instance. The objective function has two components:

- distance from customer location to the VNF - the service designed assigns a weight for the distance: wd

- the cost of deploying the VNF in a location - the service designer assigns a weight for the cost: wc

OOF optimizes function: min (wd*distance + wcx*cloud_net_value)

//MC → wc*cost + wa*fraction_allocated_resource

If the service does not care about the cost at all, it would set wc = 0. If the service designer wants to minimize cost, he could set wd=0. Note that candidates that are too far can be eliminated by a distance constraint even before the optimization. For example, if the service has a distance constraint of at most 100 kilometers, then only those cloud regions within 100 kilometers to the customer location would be considered in the objective function evaluation.

If the service designer wants to trade off between distance and cost, for example, they might set wd = 1, wc = 2. This would mean that one $1 increase in price is as valuable as 2 kilometers in distance.

Candidate 1: $100, 100 kilometers => value: 300

Candidate 2: $150, 80 kilometers => value: 380

Candidate 3: $50, 190 kilometers => value: 290 <- pick this one

Cloud Resource Partitioning for Differentiated QoS (Combined with Previous)

...

Space shortcuts

Page tree

Versions Compared

Old Version 127

New Version 128

Key

1. SO → OOF - Get Target <Cloud Owner, Cloud Region> for the Service Instances

2. OOF → Policy - Fetch Enhanced Capacity Check & Cloud Selection Policy for

Homing

4. OOF → MC - Push Cloud Agnostic Policy for the Service Instance - perform Cloud Specific Check (capability/capacity/cost metrics) for each registered Cloud Region in Multi-

Cloud

5. MC → OOF – Return a net value cost for each <cloud owner, cloud region> if the capacity check succeeds

6. OOF → SO - Return the target <cloud owner, cloud region> for the Service Instance

7. SO → MC - Deploy VNF template in the target <cloud owner, cloud region> for the Service Instance (need code changes)

OOF->MC Processing

6. OOF → SO - Return the target <cloud owner, cloud region> for the Service Instance

7. SO → MC - Deploy VNF template in the target <cloud owner, cloud region> for the Service Instance

SO Processing

SO → MC API

SO → MC Processing

SO Processing

SO → MC API

SO → MC Processing