Page History

...

Code Block

language	py
theme	Emacs
title	OOF Homing Enhanced Capacity Check & Cloud Selection Policy Example (Step 2a)
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": 
{
	{//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
		"capacityCheck": "TRUE", //perform capacity check per <cloud owner, cloud region>cost-intent":
		{
			"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  	
	{//new in R3
		"cloudOwner": ["vgw",VMware VIO"vgmux"], //"vgw"can isbe alsoa interchangeablyspecific usedcloud owner such as "vg"
"applicableResources Azure, VMware VIO, Wind River Titanium Cloud etc.
		"cloudRegion": "anyAll", //can be a specific cloud region for a cloud owner
		"identitydeployment-intent": "cloud-atrributes",
"policyScope
		{
			"name": ["vCPE", "US", "INTERNATIONAL", "ip", "vgw", "vgmux"],
"policyType": "AllPolicy"

}

3. OOF → A&AI - Fetch Cloud-Agnostic (Standardized) Capabilities for the Service Instance

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

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.

"Infrastructure Resource Isolation 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"}
			}
		}
	},
	
	{//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
		"deployment-intent": 
		{
			"name": "Infrastructure High Availability (HA) for VNF", 
		}
	}, 		  	
}

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

}

3. OOF → A&AI - Fetch Cloud-Agnostic (Standardized) Capabilities for the Service Instance

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

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 (Step 4a)
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
		"cost-intent":
		{
			"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
		}
	},			 			  	
  	
	{//new in R3
		"cloudOwner": "VMware VIO", //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
		"deployment-intent": 
		{
			"name": "Infrastructure Resource Isolation 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"}
			}
		}
	},
	
	{

Code Block

language	py
theme	Emacs
title	OOF <-> MC API Examples (Step 4a)
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
		"dollarCostEvaluationVMdeployment-Typeintent": "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	"name": "Infrastructure High Availability (HA) for VNF", 
		}
	},
	
		 			  	
  		
	{{//new in R3 + R2
		"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"
	},
}

Code Block

language	py
theme	Emacs
title	Workload Deployment Cost Policy Example (Step 5b)
linenumbers	true
collapse	true

//
//Policy relevant to MC Azure Plugin
//

//<Service, VNFC> to instanceType Mapping
{
	{
		"Service": "vCPE"
		"VNFC": "vgw", //"vgw" is also intechangeably used as "vg"	
		"cloudOwner": "Azure",
		"instanceType": "x1"
	}
}


//workload deployment cost for instance type per cloud region 
{
	{
		"cloudRegion": "5",
		"instanceType": "x1",
		"workloadDeploymentCostworkloadDeploymentBaseVMCost": "100"
	}, 
	{
		"cloudRegion": "10",
		"instanceType": "x1",
		"workloadDeploymentCostworkloadDeploymentBaseVMCost": "120"
	}, 
}

5a) MC Processing (need MC code changes)

...

For R3, Workload Deployment Cost Policy (Intent) can be stored in the form of configuration file(s) in the OOM K8S Persistent Volumes visible to the relevant MC plugin to simplify implementation. Beyond R3, this could be moved to the Policy DB. The details of the configuration are described below.

Workload deployment cost includes dollar cost of Instance Type (based on <Service, VNFC, cloud owner>) and dollar cost (or discount) of other cloud-specific features corresponding to "Cloud-Agnostic Workload Deployment Policy (Intent)" described in workflow Step 7.the intent expressed under the deployment-intent keyword in the OOF → MC API
- As an example, with respect to the Intent the deployment-intent, "Infrastructure Resource Isolation for VNF" , with "Burstable QoS" can yield potential cost savings as compared to "Guaranteed QoS" by allowing smart over-subscription while still guaranteeing isolation
Note that the operator is free to choose the method of calculating the cost which includes initial cost, support cost & operational cost.
Note that the operator is free to choose what time duration the cost metric is specified for each of the MultiVIM plugins (e.g., cost per hour, cost per month) since they will do it consistently for each of the VIMs.

"Workload Deployment Cost Policy Example" depicted above has an exemplary description of this.

For R3, to simplify implementation, all the features needed for cloud-specific realization of the deployment-intent are assumed to have no additional cost.

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

...

<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

7a) MC Processing (need MC code changes)

Parse Template (e.g. OpenStack Heat Template)
- For each VNFC, instance type in the template
  - Fetch Cloud-Agnostic Workload Deployment Policy (Intent) based on <Service (e.g. vCPE), VNFC (e.g. vGW)>
    - Value/Content: <Policy JSON>
    - Note: The policy details are in Section 7b).
  - 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 (Intent) Realization
- "Infrastructure High Availability (HA) for VNF"
  - OpenStack-based Cloud realization
    - For R3, Host-based anti-affinity using server groups //Beyond R3, Support other anti-affinity models at availability zone level etc.
    - Implementation Notes:
      - Instance "count" in heat template specifies VNFC scale out factor
      - While dynamic injection of server group into heat template is ideal, a simple starting point could be just switching to an alternate heat which is identical to the deployment template and additionally has server group
  - Azure realization
    - Availability Set?
- "Infrastructure Resource Isolation for VNF" – { "qosProperty": { {"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"} } }
  - OpenStack-based VMware VIO Cloud realization
    - This can be achieved through min guarantee -- Max or limit (upper bound) & Min or Reservation (guarantee) are part of OpenStack flavor metadata
      - https://docs.openstack.org/horizon/latest/admin/manage-flavors.html
      - https://blogs.vmware.com/openstack/resources-guarantee-openstack-and-vmware-integrated-openstack/
- - - Example
      - VNFC with "Guaranteed QoS"
        "flavor-xyz-no-oversubscription"
        vCPU (Min/Max) - 16, Mem (Min/Max) - 32GB
      - Same VNFC with "Burstable QoS", 25% over-subscription
        "flavor-xyz-25-percent-oversubscription"
        vCPU (Min) - 16, Mem (Min) - 32GB
        vCPU (Max) - 20, Mem (Max) - 40GB
    - Only certain pre-defined over-subscription values are allowed to simplify implementation
    - Implementation Notes:
      - While dynamic injection of limit/reservation into flavor is ideal, a simple starting would be to be to switch to a pre-defined flavor in the environment file
        For aforementioned example
        Original flavor -

<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

7a) MC Processing (need MC code changes)

Parse Template (e.g. OpenStack Heat Template)
- For each VNFC, instance type in the template
  - Fetch Cloud-Agnostic Workload Deployment Policy (Intent) based on <Service (e.g. vCPE), VNFC (e.g. vGW)>
    - Value/Content: <Policy JSON>
    - Note: The policy details are in Section 7b).
  - 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 (Intent) Realization
- "Infrastructure High Availability (HA) for VNF"
  - OpenStack-based Cloud realization
    - For R3, Host-based anti-affinity using server groups //Beyond R3, Support other anti-affinity models at availability zone level etc.
    - Implementation Notes:
      - Instance "count" in heat template specifies VNFC scale out factor
      - While dynamic injection of server group into heat template is ideal, a simple starting point could be just switching to an alternate heat which is identical to the deployment template and additionally has server group
  - Azure realization
    - Availability Set?
- "Infrastructure Resource Isolation for VNF" – { "qosProperty": { {"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"} } }
  - OpenStack-based VMware VIO Cloud realization
    - This can be achieved through min guarantee -- Max or limit (upper bound) & Min or Reservation (guarantee) are part of OpenStack flavor metadata
      - https://docs.openstack.org/horizon/latest/admin/manage-flavors.html
      - https://blogs.vmware.com/openstack/resources-guarantee-openstack-and-vmware-integrated-openstack/
- - - Example
      - VNFC with "Guaranteed QoS"
        "
        "flavor-xyz-no-oversubscription"
        vCPU (Min/Max) - 16, Mem (Min/Max) - 32GB
        Same VNFC with "Burstable QoS", 25% over-subscription
        Modified flavor based on Policy - "flavor-xyz-25-percent-oversubscription"
        vCPU (Min) - 16, Mem (Min) - 32GB
        vCPU (Max) - 20, Mem (Max) - 40GB
    - Only certain pre-defined over-subscription values are allowed to simplify implementation
    - Implementation Notes:
      - While dynamic injection of limit/reservation into flavor is ideal, a simple starting would be to be to switch to a pre-defined flavor in the environment file
        For aforementioned example
        Original flavor - "flavor-xyz-no-oversubscription"
        Modified flavor based on Policy - "flavor-xyz-25-percent-oversubscription"

7b) Cloud-Agnostic Workload Deployment Policy (Intent)

For R3, Cloud-Agnostic Workload Deployment Policy (Intent) can be stored in the form of configuration file(s) in the OOM K8S Persistent Volumes to simplify implementation.
- For R4 and beyond, this policy (optionally with specific realization options) will be passed from SO → MC. This is captured in the R4 and beyond (Phase 2 of the workflow --
This policy is exactly the same as the policies with "deployment-intent" in the Enhanced Capacity Check & Cloud Selection Policy for Homing described in Section 2For R3, Cloud-Agnostic Workload Deployment Policy (Intent) can be stored in the form of configuration file(s) in the OOM K8S Persistent Volumes to simplify implementation.
An exemplary policy is depicted below.

Code Block

language	py
theme	Emacs
title	Cloud-Agnostic Workload Deployment Policy (Step 7b)
linenumbers	true
collapse	true

//Policy Example 1 - VNFC VGW which is part of vCPE service
{
	"Service": "vCPE"
	"VNFC": "vgw", //"vgw" is also intechangeably used as "vg"	
	
	{
		"cloudOwner": "VMware VIO", //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
		"deployment-intent": 
		{
			"name": "Infrastructure Resource Isolation 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"}

			}
		}
	}
}


//Policy Example 2 - VNFC vDNS which is part of vLoadBalancer/vDNS service
{
	"Service": "vDNS",
	"VNFC": "vDNS", 
	
	//By default, Policy (Intent) is applicable to all cloud owners/regions unless specified.
	{		
		"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
		"deployment-intent": 
		{
			"name": "Infrastructure High Availability (HA) for VNF", 
		}
	},
	
	{
		"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
		"deployment-intent": 
		{
			"name": "Infrastructure Resource Isolation 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": 
			{		
				{"Guaranteed QoS": "TRUE"}
			}
		}
	}
}

...

Space shortcuts

Page tree

Versions Compared

Old Version 139

New Version 140

Key

4. OOF → MC - Push Cloud Agnostic Policy for the Service Instance

4. OOF → MC - Push Cloud Agnostic Policy for the Service Instance

5. MC → OOF – Return a net value 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

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