Versions Compared

Old Version 197

changes.mady.by.user Ramki Krishnan

Saved on

compared with

New Version Current

changes.mady.by.user Ramki Krishnan

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Summary: Edge ScopingArchitecture & Work Items#ONAPEdgeMVP 

...

Table of Contents

...


Distributed Edge Cloud Infrastructure Object Hierarchy (Stretch Goal - Beyond Casablanca)

Value:

  • Fine grained resource management & analytics for Distributed Edge Clouds 

...

  • Cloud SW Capability example 
    • Cloud region "x" with SR-IOV, GPU, Min-guarantee support
    • Cloud region "y" with SR-IOV support
  • Cloud HW Capability example 
    • Resource cluster "xa" in Cloud region "x" with SR-IOV and GPU support 
    • Resource cluster "xb" in Cloud region "x" with GPU support
    • Resource cluster "ya" in Cloud region "y" with SR-IOV support

Note 3:

  • 5G Service/VNF placement example
    • Constraints used by Optimization Framework (OOF)

      • 5G CU-UP VNF location to be fixed to a specific physical DC based on 5G DU, bounded by a max distance from 5G DU

    • Optimization Policy used by OOF

      • Choose optimized cloud region (or instance) for the placement of 5G CU UP for subscriber group based on the above constraints

Note 4:

  • For the 5G Service/VNF placement example in Note 3
    • 5G CU-UP VNF preferably maps to a specific Cloud region & Physical DC End Point 

Note 5:

  • For the 5G Service/VNF placement example in Note 3
    • OOF will pass the Physical DC End Point to SO as a opaque data

Note 6:

  • For the 5G Service/VNF placement example in Note 3
    • SO passes the Physical DC End Point to Multi-Cloud as a opaque data, besides the Cloud Region

Cloud-agnostic Placement/Networking & Homing Policies (Phase 1 - Casablanca MVP, Phase 2 - Stretch Goal)

...

  • Multi-Cloud Policy Framework
    • Assist OOF in target cloud region selection for VNF placement (aka homing) through intent

      • Cloud Agnostic Intent (Policy) Execution Workflow  - Steps 1- 64

    • Dynamically modify the cloud specific VNF deployment template based on cloud-specific realization of the specified intent (e.g. Infra HA for VMs within a VNF could have different realizations across different clouds)

      • Cloud Agnostic Intent (Policy) Execution Workflow  - Step 75

  • Intent Support

    • Single realization option per Cloud Region for the specified Intent

  • Impact Projects:
    • Multi-Cloud (Highest), OOF, SO (Minimal)
  • End-to-end use case demonstration:
    • vCPE (higher priority – no additional implementation dependency), vDNS
  • Types of intent supported (through OOF Policy)
    • "Infrastructure High Availability for VNF" 
    • "Infrastructure Resource Isolation for VNF": "Burstable QoS" 
    • "Infrastructure Resource Isolation for VNF": "Guaranteed QoS"

Phase 2 (Casablanca Stretch Goal) Summary (Build on Phase 1 Work):

  • Multi-Cloud Policy Framework
    • Dynamically modify the cloud specific VNF deployment template based on cloud-specific realization of the specified intent – Impact to VNF configuration 
      • E.g. High performance Intra-DC data plane networking with several realization choices
  • Intent Support
    • Multiple realization options per Cloud Region for the specified Intent
  • Major Impact Projects:
    • Multi-Cloud
  • Minor Impact Projects:
    • SO, OOF, GNF Controller
  • Wiki Link:

References: 

(warning) The sequence diagram below expands "Multi-Cloud/VNFM Deploy Apps" in Edge Scoping Sequence Diagram

Cloud Agnostic Intent (Policy) Workflow Summary (Phase 1 - Casablanca MVP):

Gliffy
size1200
nameCloud Agnostic Intent Execution Workflow
pagePin40

Cloud Agnostic Intent (Policy) Workflow Details (Phase 1 - Casablanca MVP):

Private Cloud Setup - OpenStack-based

VNFC to Instance Type Mapping

Phase 2 (Casablanca Stretch Goal) Summary (Build on Phase 1 Work):

  • Multi-Cloud Policy Framework
    • Dynamically modify the cloud specific VNF deployment template based on cloud-specific realization of the specified intent – Impact to VNF configuration 
      • E.g. High performance Intra-DC data plane networking with several realization choices
  • Intent Support
    • Multiple realization options per Cloud Region for the specified Intent
  • Major Impact Projects:
    • Multi-Cloud
  • Minor Impact Projects:
    • SO, OOF, GNF Controller
  • Wiki Link:

References: 

(warning) The sequence diagram below expands "Multi-Cloud/VNFM Deploy Apps" in Edge Architecture & Work Items Sequence Diagram

Cloud Agnostic Intent (Policy) Workflow Summary (Phase 1 - Casablanca MVP):

Gliffy
size1200
nameCloud Agnostic Intent Execution Workflow
pagePin42

Cloud Agnostic Intent (Policy) Workflow Details (Phase 1 - Casablanca MVP):

Private Cloud Setup - OpenStack-based

  • Pre-defined (including custom) flavors map to Instance types in Public Clouds
    • Pre-defined flavors are created by the Cloud Admin before the Cloud is used by ONAP for workload deployment
  • VMware VIO Configuration for Min Guarantee feature
    • Ref: https://docs.microsoftvmware.com/en-us/azure/virtual-machines/linux/sizes?toc=%2fazure%2fvirtual-machines%2flinux%2ftoc.json

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

Step 2. OOF → Policy - Fetch Cloud Selection Policy for Homing 

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

OOF Homing Enhanced Cloud Selection Policy -- JSON Schema with Use Case Examples as runnable python code:

...

languagepy
themeEmacs
titleOOF Homing Enhanced Cloud Selection Policy Example (Step 2a)
linenumberstrue
collapsetrue

...

VNFC to Instance Type Mapping

Step 1. SO → OOF - Get Target <Cloud Owner, Cloud Region> for the Service Instances (no code changes for R3)

Step 2. OOF → Policy - Fetch Cloud Selection Policy for Homing 

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

OOF Homing Enhanced Cloud Selection Policy based on Intent -- Schema with Use Case Examples as runnable python code:
Code Block
languagepy
themeEmacs
titleOOF Homing Enhanced Cloud Selection Policy Example (Step 2a)
linenumberstrue
collapsetrue
#
#Spec Reference: https://wiki.onap.org/display/DW/Edge+Scoping+MVP+for+Casablanca+-+ONAP+Enhancements#EdgeScopingMVPforCasablanca-ONAPEnhancements-Cloud-agnosticPlacement/Networking&HomingPolicies(Phase1-CasablancaMVP,Phase2-StretchGoal)
#

from jsonschema import validate

oof_cloud_selection_policy_schema = {
        "versionservice": {"type": "string"},
        "prioritypolicyName": {"type": "string"},
        "riskTypepolicyDescription": {"type": "string"},
        "templateVersion": {"type": "string"},
        "version": {"type": "string"},
        "priority": {"type": "string"},
        "riskType": {"type": "string"},
        "riskLevel": {"type": "string"},
        "guard": {"type": "string"},

        "content": {
                "type": "object",
                "required": ["cloud-cost-evaluation", "cloud-deployment-intent"],
                "properties" : {

                        # VNFC is not used in the OOF->MC path for R3
                        # This is kept to be consistent with the SO-> MC path
            			# As an example, vDNS VNF in ONAP has 3 VNFCs - DNS, Packet Gen & Load Balancer --
						# Each of the VNFCs could have different policies              													      									
                        "vnfc": {"type": "string"},

                        # evaluate cloud-specific costrealization ifof setthe specified deployment intent
                     # cost is fixed# perhappens cloudin type formulti-cloud allin workloadsthe cloud--specific simplifyingplugin
assumption for R3                      "cloud-deployment-intent": {
 # cost specified in the respective plugin through a configuration file                         "cloud-cost-evaluation" : {"type" : "booleanobject"},
                         # cloud-specific realization of the specified deployment intent"properties" : {

                     # happens in  multi-cloud in the cloud-specific plugin           # Cloud Type -- Azure, K8S, OpenStack, VMware VIO, Wind River    "cloud-deployment-intent": {Titanium
                    					# Optionally Accomodate policies per Cloud  Type
      "type": "object",             					"Cloud Type (Cloud Provider)": {"type", "array"},
                  "properties"   : {                  
                       # Cloud Type -- Azure, K8S, OpenStack, VMware VIO, Wind River Titanium      "Infrastructure High Availability for VNF": {"type", "boolean"},

       					# Optionally Accomodate policies per Cloud Type                                 					"Cloud Type (Cloud Provider)"Infrastructure Resource Isolation for VNF": {"type", "arraystring"},

                                        # Infrastructure Resource Isolation for VNF
                                  "Infrastructure High Availability for VNF": {"type", "boolean"},

   # Only certain pre-defined over-subscription values are allowed to
                                        "Infrastructure# Resourcereflect Isolationpractical fordeployment VNF": {"type", "string"},

and simplify implementation for R3
                                       # "Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage": {"type": "int"},
                                },
# Only certain pre-defined over-subscription values are allowed to                },
                },
       # reflect},
practical
deployment and simplify implementation for R3   "resources": {"type", "array"}, #"vgw" is also interchangeably used as "vg"
        "applicableResources": {"type", "string"},
        "identity": {"type", "string"},
        "policyScope": "Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage{"type", "array"},
        "policyType": {"type":, "intstring"},
}

#
#Example 1: vCPE, Burstable QoS
#vCPE: Infrastructure Resource Isolation for VNF with Burstable QoS
#
oof_cloud_selection_policy_instance1 = {
           }"service": "cloudSelectionPolicy",
        "policyName": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vCPE_VNF",
        "policyDescription": "Cloud Selection Policy for vCPE }VNFs",
        "templateVersion": "0.0.1",
      },         },
"version": "oofMulti-cloudCasablanca",
        "resourcespriority": {"type3",
"array"}, #"vgw" is also interchangeably used as "vg"        "riskType": "test",
        "applicableResourcesriskLevel": {"type2",
"string"},
        "identityguard": {"typeFalse",
"string"},
        "policyScopecontent": {"type", "array"},
                "policyTypevnfc": {"typevgw",
 "string"} }  # #Example 1: vCPE, Burstable QoS #vCPE: Infrastructure Resource Isolation for VNF with Burstable QoS
#
oof_cloud_selection_policy_instance1 = { "cloud-deployment-intent": {
             "service": "cloudSelectionPolicy",           "policyNameCloud Type (Cloud Provider)": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vCPE_VNF"{"VMware VIO"},
        "policyDescription": "Cloud Selection Policy for vCPE VNFs",
        "templateVersion 			"Infrastructure Resource Isolation for VNF": "0.0.1Burstable QoS",
        "version": "oofMulti-cloudCasablanca",
        "priority": "3"    			"Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage": 25,
        "riskType": "test",         "riskLevel": "2"},
        "guard": "False"},

        "contentresources": {
       ["vgw"], #"vgw" is also interchangeably used as "vg"
        "vnfcapplicableResources": "vgwany",
        "identity": "cloud-atrributes",
        "cloud-cost-evaluationpolicyScope": True["vCPE", "US", "INTERNATIONAL", "ip", "vgw", "vgmux"],
           "cloud-deployment-intent"policyType": {"AllPolicy"
}

#
#Example 2:
#vCPE: Infrastructure Resource Isolation for VNF with Guaranteed QoS
#
oof_cloud_selection_policy_instance2 = {
      "Cloud Type (Cloud Provider) "service": {"VMware VIOcloudSelectionPolicy"},
            			"Infrastructure Resource Isolation for VNF"policyName": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vCPE_VNF",
        "policyDescription": "BurstableCloud QoS",Selection Policy for vCPE VNFs",
        			"Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage": 25"templateVersion": "0.0.1",
        "version": "oofMulti-cloudCasablanca",
        "priority": "3",
      },  "riskType": "test",
         },
"riskLevel": "2",
        "resourcesguard": ["vgwFalse"],
#"vgw" is also interchangeably used as "vg"
 
        "content": {
      "applicableResources": "any",         "identityvnfc": "cloud-atrributesvgw",
        "policyScope": ["vCPE", "US", "INTERNATIONAL", "ip", "vgw", "vgmux"],        "cloud-deployment-intent": {
           "policyType": "AllPolicy" }  # #Example 2:	 #vCPE: 	"Infrastructure Resource Isolation for VNF": with "Guaranteed QoS",
 #
oof_cloud_selection_policy_instance2 = {              "service": "cloudSelectionPolicy" },
        "policyName": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vCPE_VNF",},

        "policyDescriptionresources": "Cloud Selection Policy for vCPE VNFs",["vgw"], #"vgw" is also interchangeably used as "vg"
        "templateVersionapplicableResources": "0.0.1any",
        "versionidentity": "oofMulticloud-cloudCasablancaatrributes",
        "prioritypolicyScope": ["3vCPE", "US",        "riskType": "test""INTERNATIONAL", "ip", "vgw", "vgmux"],
        "riskLevelpolicyType": "2AllPolicy",
}

#
#Example     "guard": "False",

        "content": {
       3:
#vDNS: Infrastructure HA for VNF & Infrastructure Resource Isolation for VNF with Burstable QoS
#
oof_cloud_selection_policy_instance3 = {
        "vnfcservice": "vgwcloudSelectionPolicy",
        "policyName": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vDNS_VNF",
      "cloud-cost-evaluation  "policyDescription": True,"Cloud Selection Policy for vDNS VNFs",
        "templateVersion": "0.0.1",
        "cloud-deployment-intentversion": {"oofMulti-cloudCasablanca",
        "priority": "3",
       	  	"Infrastructure Resource Isolation for VNF"riskType": "test",
        "riskLevel": "Guaranteed QoS2",
        "guard": "False",

     },   "content": {
     },           "resourcesvnfc": ["vgwvdns"],
 #"vgw" is also interchangeably used as "vg"         "applicableResourcescloud-deployment-intent": {
"any",         "identity": "cloud-atrributes",         "policyScope": ["vCPE", "US     "Cloud Type (Cloud Provider)": {"VMware VIO", "INTERNATIONALAzure"},
"ip", "vgw", "vgmux"],         "policyType": "AllPolicy" }  # #Example 3: #vDNS: Infrastructure HA for VNF & "Infrastructure ResourceHigh IsolationAvailability for VNF": withTrue,
Burstable QoS # oof_cloud_selection_policy_instance3 = {         "service": "cloudSelectionPolicy",         "policyNameInfrastructure Resource Isolation for VNF": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vDNS_VNFBurstable QoS",
         "policyDescription": "Cloud Selection Policy for vDNS VNFs",         "templateVersion": "0.0.1",
        "version": "oofMulti-cloudCasablanca",Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage": 25,
          "priority": "3"      },
        "riskType": "test",},

        "riskLevelresources": ["2vDNS"],
        "guardapplicableResources": "Falseany",

        "contentidentity": {"cloud-atrributes",
        "policyScope":        "vnfc": "vdns"["vDNS", "US", "INTERNATIONAL", "vDNS"],
        "policyType": "AllPolicy"
}

#
#   "cloud-cost-evaluation"Example 4:
True,# vDNS: Infrastructure HA for VNF & Infrastructure Resource Isolation for VNF
# with Guaranteed QoS
#
"cloud-deployment-intent":oof_cloud_selection_policy_instance4 = {
        "service": "cloudSelectionPolicy",
        "policyName": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vDNS_VNF",
     "Cloud Type (Cloud Provider)"policyDescription": {"VMware VIO", "Azure"}"Cloud Selection Policy for vDNS VNFs",
        "templateVersion": "0.0.1",
        "version": "oofMulti-cloudCasablanca",
    "Infrastructure High Availability for VNF"priority": True"3",
        "riskType": "test",
        "riskLevel": "2",
    "Infrastructure Resource Isolation for VNF"guard": "Burstable QoSFalse",

         "content": {
                "vnfc": "vdns",
                "Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage": 25cloud-deployment-intent": {
                        "Infrastructure High Availability for VNF": True,
                        "Infrastructure Resource Isolation for VNF": "Guaranteed QoS",
                },
        },

        "resources": ["vDNS"],
        "applicableResources": "any",
        "identity": "cloud-atrributes",
        "policyScope": ["vDNS", "US", "INTERNATIONAL", "vDNS"],
        "policyType": "AllPolicy"
}

#
# Example 4:
# vDNS: Infrastructure HA for VNF & Infrastructure Resource Isolation for VNF
# with Guaranteed QoS
#
validate(oof_cloud_selection_policy_instance1, oof_cloud_selection_policy_schema)
validate(oof_cloud_selection_policy_instance2, oof_cloud_selection_policy_schema)
validate(oof_cloud_selection_policy_instance3, oof_cloud_selection_policy_schema)
validate(oof_cloud_selection_policy_instance4 = {
        "service": "cloudSelectionPolicy",
        "policyName": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vDNS_VNF",
        "policyDescription": "Cloud Selection Policy for vDNS VNFs",
        "templateVersion": "0.0.1",
        "version": "oofMulti-cloudCasablanca",
        "priority": "3",
        "riskType": "test",
        "riskLevel": "2",
        "guard": "False",

        "content": {
                "vnfc": "vdns",
                "cloud-cost-evaluation": True,
                "cloud-deployment-intent": {
                        "Infrastructure High Availability for VNF": True,
                        "Infrastructure Resource Isolation for VNF": "Guaranteed QoS",
                },
        },

        "resources": ["vDNS"],
        "applicableResources": "any",
        "identity": "cloud-atrributes",
        "policyScope": ["vDNS", "US", "INTERNATIONAL", "vDNS"],
        "policyType": "AllPolicy"
}

validate(oof_cloud_selection_policy_instance1, oof_cloud_selection_policy_schema)
validate(oof_cloud_selection_policy_instance2, oof_cloud_selection_policy_schema)
validate(oof_cloud_selection_policy_instance3, oof_cloud_selection_policy_schema)
validate(oof_cloud_selection_policy_instance4, oof_cloud_selection_policy_schema)

Step 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>. OOF will prune any <cloud owner, cloud region> which is not satisfying the standardized capabilities.

Step 4, OOF --> MC evaluate cost of deployment (aligned to the SO/MC API defined by SO Casablanca HPA Design to minimize the terminology set)

*** Assume: VNFC is equalivent to VM, VNF is equivalent of heat stack.

Code Block
titlecost_evaluation
collapsetrue
Request URI:
	POST http://{msb ip}:{msb port}/api/multicloud/v1/cost_evaluation

Request body:


[
    {
        "cloud-owner": "owner1",
        "cloud-region-id": "region1",

        "directives":[ 
         { 
            "vnfc_directives":[ 
               { 
                  "vnfc_id":"<ID of VNFC>", /*optional, but keep aligned to OOF/SO/MC API to make it simple*/
                  "directives":[
                     { 
                        "directive_name":"<Name of directive,example flavor_directive>",
                        "attributes":[ 
                           { 
                              "attribute_name":"<name of attribute, such as flavor label>",
                              "attribute_value":"<value such as cloud specific flavor>"
                           }
                        ]
                     },
                     { 
                        "directive_name":"<Name of directive,example vnic-info>",
                        "attributes":[ 
                           { 
                              "attribute_name":"<name of attribute, such as vnic-type>",
                              "attribute_value":"<value such as direct/normal>"
                           },
                           { 
                              "attribute_name":"<name of attribute, such as provider netweork>",
                              "attribute_value":"<value such as physnet>"
                           }
                        ]
                     }
                  ]
               }
            ]
         },
         {
            "vnf_directives":{ 
               "directives":[ 
                  { 
                     "directive_name":"<Name of directive>",
                     "attributes":[ 
                        { 
                           "attribute_name":"<name of attribute>",
                           "attribute_value":"<value>"
                        }
                     ]
                  },
                  { 
                     "directive_name":"<Name of directive>",
                     "attributes":[ 
                        { 
                           "attribute_name":"<name of attribute>",
                           "attribute_value":"<value >"
                        },
                        { 
                           "attribute_name":"<name of attribute>",
                           "attribute_value":"<value >"
                        }
                     ]
                  }
               ]
            }
         }
        ]
    },
    {
    
        "cloud-owner": "owner2",
        "cloud-region-id": "region2",

        "directives": []
    }
]

Response:


[
    {
        "cloud-owner": "owner1",
        "cloud-region-id": "region1",
        "net-value": 100
    },
    {
        "cloud-owner": "owner2",
        "cloud-region-id": "region2",
            "net-value": 101
    }
]

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

4a) OOF Processing

The OOF ↔ MC cloud selection API, described below, is filled based on the Cloud Selection Policy for Homing retrieved in step 2) – need OOF code changes. 

OOF <-> MC Cloud Selection API -- JSON Schema with Use Case Examples as runnable python code:

Code Block
languagepy
themeEmacs
titleOOF <-> MC API Examples (Step 4a)
linenumberstrue
collapsetrue
//flexibility of having cloud type in the new API provides fine grained control, addresses capacity/cost differences across different cloud owners/regions and ensures backward compatibility

Proposed API URL: http://msb:80/api/multicloud/v0/intent_based_cloud_selection


#
#Spec Reference: https://wiki.onap.org/display/DW/Edge+Scoping+MVP+for+Casablanca+-+ONAP+Enhancements#EdgeScopingMVPforCasablanca-ONAPEnhancements-Cloud-agnosticPlacement/Networking&HomingPolicies(Phase1-CasablancaMVP,Phase2-StretchGoal)
#

from jsonschema import validate

oof_mc_policy_api_request_schema = {
        #list of VIM ids
        "Cloud Owner & Cloud Region List (VIM ids)": {"type", "array"},

        "oof-mc-policy-api-request": {
                "type": "array",
                "items": { "$ref": "#/definitions/xxx1" }
        },
        "definitions": {
                "xxx1": {
                        "type": "object",
                        "required": ["cloud-cost-evaluation", "cloud-deployment-intent"],
                        "properties" : {

                                # VNFC is not used in the OOF->MC path for R3
                                # This is kept to be consistent with the SO-> MC path
                                # As an example, vDNS VNF in ONAP has 3 VNFCs-DNS, Packet Gen & Load Balancer                      # each of the VNFCs could have different cloud policies
                                "vnfc": {"type": "string"},

                                # evaluate cloud cost if set
                                # cost is fixed per cloud type for all workloads, simplifying assumption for R3
                                # cost specified in the respective plugin through a configuration file
                                "cloud-cost-evaluation" : {"type" : "boolean"},

                                # cloud-specific realization of the specified deployment intent
                                # happens in multi-cloud in the cloud-specific plugin
                                "cloud-deployment-intent": {
                                                "type": "array",
                                                "items": { "$ref": "#/definitions/xxx2" }
                                },
                                "definitions": {
                                        "xxx2": {
                                                "type": "object",
                                                "properties" : {
                                                        "Infrastructure High Availability for VNF": {"type", "boolean"},

                                                        "Infrastructure Resource Isolation for VNF": {"type", "string"},

                                                        # Infrastructure Resource Isolation for VNF
                                                        # Only certain pre-defined over-subscription values are allowed to
                                                        # reflect practical deployment and simplify implementation for R3
                                                        "Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage": {"type": "int"},
                                                },
                                        },
                                },
                        },
                },
        },
}

oof_mc_policy_api_response_schema = {
        "oof-mc-policy-api-response": {
                "type": "array",
                "items": { "$ref": "#/definitions/xxx" }
        },
        "definitions": {
                "xxx": {
                        "type": "object",
                        "required": [ "VIM id", "net-value" ],
                        "properties": {

                                # VIM id
                                "VIM id": {
                                  "type": "string",
                                },

                                # For R3, net-value signifies cost per VIM id
                                # Referring to cloud-cost-evaluation in the API from OOF -> MC
                                        # cost is fixed per cloud type for all workloads
                                        # cost specified in the respective plugin through a configuration file
                                "net-value": {
                                  "type": "number",
                                }
                        }
                }
        }
}

#
#Example 1: vCPE, Burstable QoS
#vCPE: Infrastructure Resource Isolation for VNF with Burstable QoS
#
oof_mc_policy_api_instance1 = {
        #list of VIM ids
        "Cloud Owner & Cloud Region (VIM id)": {"Azure 1", "Azure 2", "VMware VIO 1"},

        "oof-mc-policy-request": [
                {
                        "vnfc": "vgw",
                        #list of VIM ids

                        "cloud-deployment-intent": [
                                {
                                                "Infrastructure Resource Isolation for VNF": "Burstable QoS",
                                                "Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage": 25,
                                }
                        ],
                },
        ]
}

#
#Example 2:
#vCPE: Infrastructure Resource Isolation for VNF with Guaranteed QoS
#
oof_mc_policy_api_instance2 = {
        #list of VIM ids
        "Cloud Owner & Cloud Region List (VIM ids)": {"Azure 1", "Azure 2", "VMware VIO 1", "Wind River Titanium 1"},

        "oof-mc-policy-request": [
                {
                        "vnfc": "vgw",
                        "cloud-cost-evaluation": True,

                        "cloud-deployment-intent": [
                                {
                                        "Infrastructure Resource Isolation for VNF": "Guaranteed QoS",
                                }
                        ],
                },
        ],
}

#
#Example 3:
#vDNS: Infrastructure HA for VNF & Infrastructure Resource Isolation for VNF with Burstable QoS
#
oof_mc_policy_api_instance3 = {
        #list of VIM ids
        "Cloud Owner & Cloud Region List (VIM ids)": {"Azure 1", "Azure 2", "VMware VIO 1", "Wind River Titanium 1"},

        "oof-mc-policy-request": [
                {
                        "vnfc": "vdns",
                        "cloud-cost-evaluation": True,
                        "cloud-deployment-intent": [
                                {
                                        "Infrastructure High Availability for VNF": True,
                                        "Infrastructure Resource Isolation for VNF": "Burstable QoS",
                                        "Infrastructure Resource Isolation for VNF - Burstable QoS Oversubscription Percentage": 25,
                                }
                        ],
                }
        ],
}

#
# Example 4:
# vDNS: Infrastructure HA for VNF & Infrastructure Resource Isolation for VNF
# with Guaranteed QoS
#
oof_mc_policy_api_instance4 = {
        #list of VIM ids
        "Cloud Owner & Cloud Region List (VIM ids)": {"Azure 1", "Azure 2", "VMware VIO 1", "Wind River Titanium 1"},
        "oof-mc-policy-request": [
                {
                        "vnfc": "vdns",
                        "cloud-cost-evaluation": True,
                        "cloud-deployment-intent": [
                                {
                                        "Infrastructure High Availability for VNF": True,
                                        "Infrastructure Resource Isolation for VNF": "Guaranteed QoS",
                                },
                        ],
                },
        ],
}

oof_mc_policy_api_response_instance = {
        "oof-mc-policy-api-response": [
                {
                        "VIM id": "Azure 1",
                        "net-value": 100
                },
                {
                        "VIM id": "VMware VIO 1",
                        "net-value": 101
                },
                {
                        "VIM id": "Wind River Titanium 2",
                        "net-value": 102
                },
                {
                        "VIM id": "Wind River Titanium 1",
                        "net-value": 102
                },
        ],
}

validate(oof_mc_policy_api_instance1, oof_mc_policy_api_request_schema)
validate(oof_mc_policy_api_instance2, oof_mc_policy_api_request_schema)
validate(oof_mc_policy_api_instance3, oof_mc_policy_api_request_schema)
validate(oof_mc_policy_api_instance4, oof_mc_policy_api_request_schema)

validate(oof_mc_policy_api_response_instance, oof_mc_policy_api_response_schema)
MC Workload Deployment Cost Policy -- JSON Schema with Use Case Examples as runnable python code:
Code Block
languagepy
themeEmacs
titleWorkload Deployment Cost Policy Example (Step 5b)
linenumberstrue
collapsetrue
#
#Spec Reference: https://wiki.onap.org/display/DW/Edge+Scoping+MVP+for+Casablanca+-+ONAP+Enhancements#EdgeScopingMVPforCasablanca-ONAPEnhancements-Cloud-agnosticPlacement/Networking&HomingPolicies(Phase1-CasablancaMVP,Phase2-StretchGoal)
#

from jsonschema import validate

mc_workload_deployment_cost_policy_schema = {
        "cloudProviderWorkloadDeploymentCost": {
                "type": "array",
                "items": { "$ref": "#/definitions/xxx" }
        },
        "definitions": {
                "xxx": {
                        "type": "object",
                        "required": [ "cloudProvider", "workloadDeploymentCost" ],
                        "properties": {

                                # VIM id
                                "cloudProvider": {
                                  "type": "string",
                                },

                                # For R3, netValue signifies cost per VIM id
                                # Referring to cost-intent in the API from OOF -> MC
                                        # cost is fixed per cloud type for all workloads
                                        # cost specified in the respective plugin through a configuration file
                                "workloadDeploymentCost": {
                                  "type": "number",
                                }
                        }
                }
        }
}

mc_workload_deployment_cost_policy_instance1 = {
        "cloudProviderWorkloadDeploymentCost": [
                {
                        "cloudProvider": "Azure",
                        "workloadDeploymentCost": 101
                },
        ],
}

mc_workload_deployment_cost_policy_instance2 = {
        "cloudProviderWorkloadDeploymentCost": [
                {
                        "cloudProvider": "Wind River Titanium Cloud",
                        "workloadDeploymentCost": 100
                },
        ],
}

validate(mc_workload_deployment_cost_policy_instance1, mc_workload_deployment_cost_policy_schema)
validate(mc_workload_deployment_cost_policy_instance2, mc_workload_deployment_cost_policy_schema)

5a) MC Processing (need MC code changes)

For each cloud owner

  • Parse OOF → MC Policy (Intent) API 
  • If a Cloud owner does not support a specific "deployment-intent"
    • Drop all the cloud regions for the cloud owner from the candidate list
  • For each cloud region // Public cloud could have different costs in different geographic locations
    • Compute net_value based on cost
      • net_value = net_value + workload_deployment_cost 
        • If Plugin of cloud owner supports cost based on "dollarCostEvaluationVM-Type" and/or "dollarCostEvaluationVM-FeatureGroup"
          • The workload deployment cost is computed per <instance type, cloud region> based on workload deployment cost policy described in Step 5b).
            • Instance Type is derived from <Service, VNFC, cloud owner>
            • More details are in 5b)
          • Implementation Notes:
            • It is not mandatory for all plugins to implement this feature since the OOF → MC API has the flexibility of turning on this feature per <cloud owner, cloud region>
        • Else
          • The workload deployment cost is computed as a fixed cost per plugin

5b) Workload Deployment Cost Policy - Configured by the Operator

The operator/service provider who uses ONAP will choose which VIMs to use and include the appropriate MC plugins in his ONAP deployment. For example, let’s assume they pick private Openstack, private VMWare, and public Azure as the platform to run their services on.

For R3, Workload Deployment Cost Policy 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.

  • By default, each plugin supports a fixed cost for all workloads
    • Optionally, plugin of cloud owner can support cost based on "dollarCostEvaluationVM-Type" and/or "dollarCostEvaluationVM-FeatureGroup"
      • Where workload deployment cost includes dollar cost of VM Instance Type (based on <Service, VNFC, cloud owner>) and dollar cost (or discount) of other cloud-specific feature groups corresponding to the intent expressed under the deployment-intent keyword in the OOF → MC API
        • As an example, with respect to 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.

Step 5. MC →  OOF – Return a net value for each <cloud owner, cloud region> 

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

Casablanca Goal for implementation simplification

Select one of the clouds which meets the cost hard constraint, e.g. cost <= x. This is similar to current capacity check implementation, where one of the cloud which passes the capacity check is selected.

Stretch Goal for Casablanca

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

...

, oof_cloud_selection_policy_schema)

Step 3. OOF → A&AI - Fetch Cloud-Agnostic (Standardized) Capabilities for the Service Instance (no code changes for R3)

3a) OOF Processing - Perform Cloud Agnostic Capability check for each <cloud owner, cloud region>. OOF will prune any <cloud owner, cloud region> which is not satisfying the standardized capabilities.

Step 4. OOF → SO - Return the target <cloud owner, cloud region> for the Service Instance + deployment-intent per vnfc (code changes in OOF for R3)

OOF

...

↔

...

SO

...

API

...

extension

...

- aligned to the OOF/SO API defined by SO Casablanca HPA Design to minimize the terminology set. The data between OOF to SO and SO to MC is identical -- details of the API are in section 5.

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

...

(code changes in Multi-Cloud for R3)

5) 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 VNFC (e.g. vGW)
        • Value/Content: <Policy JSON> 
      • Parse Policy JSON coming in the SO ↔ MC directives API
      • Modify template (if needed) according to Intent 
        • Intent examples of interest for R3 
          • "Infrastructure High Availability (HA) for VNF" 
          • "Infrastructure Resource Isolation for VNF"   
            • "Burstable QoS"
          • "Infrastructure Resource Isolation for VNF"   
            • "Guaranteed QoS"

  • Policy (Intent) Realization

    • Determining the flavor (OpenStack-based VIMs) # same logic applies for instance type in Azure
      • Each VNFC uniquely maps to a Flavor - for e.g. VNFC "vgw" maps to "vgw-base", "vDNS" maps to "vDNS-base"
      • Beyond Casablanca
        • VNFC intent to realization mapping happens through A&AI. 
    • "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 template 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"} } }

        • Example 
          • VNFC "vgw" with "Guaranteed QoS" 
            • vCPU (Min/Max) - 16, Mem (Min/Max) - 32GB 
            • Maps to "vgw-Guaranteed-QoS" flavor for OpenStack-based VIMs
            • Same VNFC with "Burstable QoS", 25% over-subscription 
              • vCPU (Min) - 16, Mem (Min) - 32GB 
              • vCPU (Max) - 20, Mem (Max) - 40GB  
              • Maps to "vgw-Burstable-QoS-25-percent-oversubscription" flavor for OpenStack-based VIMs
          • VNFC "vDNS" with "Guaranteed QoS" & "Infrastructure High Availability"
            • Maps to "vDNS-Guaranteed-QoS" flavor and "vDNS-infrastructure-high-availability" heat template
        • 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" 
    • Implementation Notes:
      • From an implementation stand point, MC would be exposing a Workload Deployment Policy (Intent) API
        • Input : deployment-intent, cloud owner, cloud region, deployment template, deployment environment file, ...
        • Output : Success or Failure with reason, modified deployment template, modified deployment environment file, ...
SO ↔ MC API extension - aligned to the SO/MC API defined by SO Casablanca HPA Design to minimize the terminology set

...

  • Use Cases for Integration testing
    • vCPE
    Deployment-Intent 
    • 1. 
      • In the current state, this use case cannot support the intent "Infra HA for VMs in a VNF"
      • This use case has been tested in R2 with OOF↔MC capacity check API
    • vDNS 
      • Can support intent "Infra HA for VMs in a VNF" and "Infrastructure Resource Isolation for VNF"
      • Nothing additional needed in OOF or MC
      • Changes needed in SO to call OOF API
        • Marcus from Intel is driving this
  • Policy DB – is there any restriction on the type of json objects that can be stored?
    • Matti to follow up with Ankit

Implementation trade offs for Casablanca (R3) and potential Dublin (R4) plan:

      • for VMs in a VNF"
      • This use case has been tested in R2 with OOF↔MC capacity check API
    • vDNS 
      • Can support intent "Infra HA for VMs in a VNF" and "Infrastructure Resource Isolation for VNF
      " – { "qosProperty": { {"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"} } }
      • Casablanca Plan
        • Only certain pre-defined over-subscription values are allowed to reflect practical deployment and simplify implementation 
      • Dublin & Beyond Potential Plan
        • Creating instance types on demand for private clouds - to study
    • 2. Cloud-agnostic Workload Deployment Policy (Intent) 
      • Casablanca Plan
        • Cloud-Agnostic Workload Deployment Policy (Intent) can be directly mapped to specific realization (e.g. OpenStack Flavor, Azure Instance Type) to simplify implementation.  
      • Dublin & Beyond Potential Plan
        • VIM Capability Discovery to populate Intent in A&AI aligning taking into account Cloud selection policy based on cost specific to Intent (leverage similarities to HPA label discovery supported since R2)
          • VIM selection – Intent to be populated in A&AI for capability matching 
          • VIM Deployment realization - Intent(s) to specific realization mapping (e.g. OpenStack Flavor, Azure Instance Type) to be populated in A&AI 
    Policy-based & cloud-selection
    • 3. Tenant Information is not passed in the OOF → MC API
      • Casablanca Plan
        • The tenant information is derived from a simple mapping function per <cloud owner, cloud region>
          • A simple mapping would be a tenant per <cloud owner, cloud region> as part of Multi-VIM plugin configuration.
          • Need to make sure that this scheme is synchronous with the SO → MC API path
      • Dublin & Beyond Potential Plan
        • Pass Tenant Information per <cloud owner, cloud region> in the OOF → MC API
    • 4. VM Instance type/VM Feature Group dollar-cost-based cloud selection 

      • Casablanca Plan

        • By default, the workload deployment cost is computed as a fixed cost per plugin

          • VM Instance type/VM Feature Group dollar-cost-based cloud selection is optional for all Multi-Cloud Plugins

      • Dublin & Beyond Potential Plan

        Deep dive further on dollar-cost-based cloud selection models/implementation for public/private clouds "
      • Nothing additional needed in OOF or MC
      • Changes needed in SO to call OOF API
        • Marcus from Intel is driving this
  • Policy DB – is there any restriction on the type of json objects that can be stored?
    • Matti to follow up with Ankit

Implementation trade offs for Casablanca (R3) and potential Dublin (R4) plan:

  • Deployment-Intent 
    • 1. "Infrastructure Resource Isolation for VNF" – { "qosProperty": { {"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"} } }
      • Casablanca Plan
        • Only certain pre-defined over-subscription values are allowed to reflect practical deployment and simplify implementation 
      • Dublin & Beyond Potential Plan
        • Creating instance types on demand for private clouds - to study
    • 2. Cloud-agnostic Workload Deployment Policy (Intent) 
      • Casablanca Plan
        • Cloud-Agnostic Workload Deployment Policy (Intent) can be directly mapped to specific realization (e.g. OpenStack Flavor, Azure Instance Type) to simplify implementation.  
      • Dublin & Beyond Potential Plan
        • VIM Capability Discovery to populate Intent in A&AI aligning taking into account Cloud selection policy based on cost specific to Intent (leverage similarities to HPA label discovery supported since R2)
          • VIM selection – Intent to be populated in A&AI for capability matching 
          • VIM Deployment realization - Intent(s) to specific realization mapping (e.g. OpenStack Flavor, Azure Instance Type) to be populated in A&AI 

Cloud Resource Partitioning for Differentiated QoS (Combined with Previous)

...

  • Applicable to all use cases
  • Casablanca Targets:
    • vCPE (Enable Tiered service offering); 5G Network Slicing (Stretch Goal) 

References:

Edge Automation Requirement:

...

View file
namePromethus-aggregation.pdf
height250

ONAP Edge Analytics with DCAE/DMaaP independent of closed loop (Stretch Goal - Beyond Casablanca)

Value

  • 5G Analytics

ONAP ComponentLife cycle phaseEnhancements
OOM - ONAP CentralDeploy
  • Separate ONAP-edge Instance per 'edge domain', (ie., separate from onap-central instance, of course)
    • Note: Independent of any Edge CP's Orchestration components.
  • SP uses a central-OOM with a 'policy' for deployment of an onap-edge instance, e.g., xyz edge provider with abc components, etc.
    • However, onap-edge instance can be 'lighter weight' with subset of components needed (per MVP discussed below)
    • Desirable to managed as a separate K8s cluster (ie., separate from onap-central instance, of course) and, only for onap-edge use, ie., don't use for other 'workloads' like network apps or 3rd party apps
  • Central OOM to deploy the following ONAP edge instance
    • DMaaP with mirror capability


Multi-Cloud Deployment in Edge Cloud (Stretch Goal - Beyond Casablanca)

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyMULTICLOUD-262

...