Contents

Summary

Introduction

The OOF retrieves applicable constraints and objective functions as policies from the policy platform. These policies are retrieved at runtime, thus allowing an operator to change policies as and when needed. These policies are specified using policy models that are on-boarded during the OOF application deployment-time in the policy platform. The OOF-related policy models are typically derived from the constraints and objective functions of an OOF-application. Currently, for R2, these models will be pushed into the policy platform manually using the OOF policy uploader module.

Policy Platform

The OOF currently relies on the following features of the policy platform:

  • Policy specification: Optimization constraints and objective functions can be specified in terms of policies by service providers and operators.
  • Policy prioritization: Policies capturing constraints and objectives can be prioritized.
  • Policy searching and filtering: OOF policies can be searched and filtered based on different criteria; by scope or by name patterns.

Resources Related to Policy

OOF Policies (multiple applications)

OOF-HAS Policies

OOF-HAS Service Design Policies

Service design policies are typically defined as a part of a service design model and evaluated/enforced prior to the service instantiation phase. For example, Hardware Platform Enablement (HPA) policies are defined in an SDC service model and evaluated/enforced during the homing optimization process in ONAP.

The HPA requirements are captured in a VNF descriptor provided by a vendor. During the service-design phase, these requirements are extracted out from the VNF descriptor and captured in a service model. Some of the HPA requirements cannot be changed during the lifecycle of a service; while other optional requirements can be changed by a service designer or operator over time (e.g. the use of SR-IOV may be preferred by an operator if the SR-IOV capability is optionally provided by a vendor). Once a service model is designed and uploaded into the SDC repository, SDC notifies the policy service about the distribution of a new service model. The policy service then fetches the service model and extracts out the HPA requirements through model decomposition. Next, the policy service creates HPA policies for the homing service (OOF-HAS) by populating the HPA requirements in policy models provided by OOF, and stores the policies in a repository. When the homing service receives a homing request from SO, the homing service asks for the associated HPA policies from the policy platform. Finally, the homing service finds homing solutions based on the evaluation of the received HPA policies and returns the solutions to SO.

As per meeting minutes here: OOF 2018-02-19 Meeting Notes, it was understood that all HPA requirements for a given VM can be put in one policy or across different policies. Also, it was discussed that each HPA capability can be enhanced to include mandatory and score attributes. Keeping this in mind, HPA capabilities are defined here. As indicated, policy can have multiple capabilities.

Template for the HPA policies 
{
    "service": "{the model name of a policy}",
    "policyName": "{policy scope folder}.{policy name; must be unique}",
    "description": "{description of a policy}",
    "templateVersion": "{policy model version}",
    "version": "{policy version}",
    "priority": "{priority in 1-10; larger the number higher the priority is}",
    "riskType": "{the type of risk}",
    "riskLevel": "{the level of risk}",
    "guard": "{True/False flag to indicate whether guard is applicable or not}",
    "content": { 
      "resource": "{resource name}",
      "identity": "{policy identity}",
      "policyScope": ["{a tag representing policy scope}"],
      "policyType": "{policy type}",
      "flavorFeatures": [
        {
          "flavorLabel": "{VM/VFC id}",
          "flavorProperties":[
            {
              "hpa-feature" : "{HPA feature type}",
              "mandatory" : "{mandatoriness of the feature}",
              "score" : "{priority of this feature if the feature is not mandatory for VM}"
              "architecture": "{supported architecuture}",
              "hpa-version": "{version for hpa capability}",
              "hpa-feature-attributes": [
                {
                  "hpa-attribute-key": "{attribute name}", 
                  "hpa-attribute-value": "{attribute value}",
                  "operator": "{comparison operator}", 
                  "unit": "{the unit of an attribute}"}
              ]
            }
          ] 
        }
      ]
    }
}

Template for the HPA policies.

HPA Policy Example 
{
    "service": "hpaPolicy",
    "policyName": "oofBeijing.hpaPolicy_vGMuxInfra",
    "description": "HPA policy for vGMuxInfra",
    "templateVersion": "0.0.1",
    "version": "1.0",
    "priority": "3",
    "riskType": "test",
    "riskLevel": "2",
    "guard": "False",
    "content": { 
      "resources": "vGMuxInfra",
      "identity": "hpaPolicy_vGMuxInfra",
      "policyScope": ["vCPE", "US", "INTERNATIONAL", "ip", "vGMuxInfra"],
      "policyType": "hpaPolicy",
      "flavorFeatures": [
        {
          "flavorLabel": "flavor_label_vm_01",
          "flavorProperties":[
            {
              "hpa-feature" : "cpuTopology",
              "mandatory" : "True",
              "architecture": "generic",
              "hpa-version": "v1",
              "hpa-feature-attributes": [
                {"hpa-attribute-key":"numCpuSockets", "hpa-attribute-value": "2","operator": ">=", "unit": ""},
                {"hpa-attribute-key":"numCpuSockets", "hpa-attribute-value": "4","operator": "<=", "unit": ""},
                {"hpa-attribute-key":"numCpuCores", "hpa-attribute-value": "2", "operator":">=", "unit": ""},
                {"hpa-attribute-key":"numCpuCores", "hpa-attribute-value": "4", "operator":"<=", "unit": ""},
                {"hpa-attribute-key":"numCpuThreads", "hpa-attribute-value": "4", "operator":">=", "unit": ""},
                {"hpa-attribute-key":"numCpuThreads", "hpa-attribute-value": "8", "operator":"<=", "unit": ""}
              ]
            },
            {
              "hpa-feature" : "basicCapabilities",
              "mandatory" : "True",
              "architecture": "generic",
              "hpa-version": "v1",
              "hpa-feature-attributes": [
                {"hpa-attribute-key": "numVirtualCpu", "hpa-attribute-value": "6", "operator": "=", "unit": ""},
                {"hpa-attribute-key": "virtualMemSize", "hpa-attribute-value":"6", "operator": "=", "unit": "GB"}
              ]
            },
            {
              "hpa-feature" : "ovsDpdk",
              "mandatory" : "False",
              "score" : "3",
              "architecture": "generic",
              "hpa-version": "v1",
              "hpa-feature-attributes": [
                 {"hpa-attribute-key":"dataProcessingAccelerationLibrary", "hpa-attribute-value":"ovsDpdk_version", "operator": "=", "unit":""}
              ]
            },
            {
              "hpa-feature" : "cpuInstructionSetExtensions",
              "mandatory" : "True",
              "architecture": "INTEL-64",
              "hpa-version": "v1",
              "hpa-feature-attributes": [
                {"hpa-attribute-key":"instructionSetExtensions", "hpa-attribute-value":["<CPUINST>", "<CPUINST>"] "operator": "ALL", "unit":""}
              ]
            }
          ] 
        },
        {
          "flavorLabel": "flavor_label_vm_02",
          "flavorProperties":[
            {
              "hpa-feature" : "cpuPinningy",
              "mandatory" : "True",
              "architecture": "generic",
              "hpa-version": "v1",
              "hpa-feature-attributes": [
                {"hpa-attribute-key":"logicalCpuThreadPinningPolicy", "hpa-attribute-value":"<CPUTHREADPOLICY>", "operator": "=", "unit":""},
                {"hpa-attribute-key":"logicalCpuPinningPolicy", "hpa-attribute-value": "<CPUPOLICY>","operator": "=", "unit":""},
              ]
            },
            {
              "hpa-feature" : "basicCapabilities",
              "mandatory" : "True",
              "architecture": "generic",
              "hpa-version": "v1",
              "hpa-feature-attributes": [
                {"hpa-attribute-key": "numVirtualCpu", "hpa-attribute-value": "6", "operator": "=", "unit": ""},
                {"hpa-attribute-key": "virtualMemSize", "hpa-attribute-value":"6", "operator": "=", "unit": "GB"}
              ]
            },
            {
              "hpa-feature" : "localStorage",
              "mandatory" : "False",
              "score" : "5",
              "architecture": "generic",
              "hpa-version": "v1",
              "hpa-feature-attributes": [
                {"hpa-attribute-key": "diskSize", "hpa-attribute-value": "2", "operator": "=", "unit": "GB"},   
      	        {"hpa-attribute-key": "ephemeralDiskSize", "hpa-attribute-value": "2", "operator": "=", "unit": "GB"},
		        {"hpa-attribute-key": "swapMemSize", "hpa-attribute-value":"16", "operator": "=", "unit": "MB"},
              ]
            },
            {
              "hpa-feature" : "pcie",
              "mandatory" : "True",
              "architecture": "generic",
              "hpa-version": "v1",
              "hpa-feature-attributes": [
                {"hpa-attribute-key": "pciCount", "hpa-attribute-value": "2", "operator": "=", "unit": ""},
                {"hpa-attribute-key": "pciVendorId", "hpa-attribute-value":"8086", "operator": "=", "unit": ""},
	            {"hpa-attribute-key": "pciDeviceId", "hpa-attribute-value": "2", "operator": "=", "unit": ""} 
                {"hpa-attribute-key": "functionType", "hpa-attribute-value": "<PCITYPEVALUE>","operator": "=", "unit": ""} 
              ]
            }
          ] 
        },
        {
          "flavorLabel": "flavor_label_vm_03",
          "flavorProperties":[
            {
              "hpa-feature" : "numa",
              "mandatory" : "False",
              "score" : "5",
              "architecture": "generic",
              "hpa-version": "v1",
              "hpa-feature-attributes": [
                {"hpa-attribute-key": "numaNodes", "hpa-attribute-value": "2", "operator": "=", "unit": ""},
                {"hpa-attribute-key": "numaCpu-0", "hpa-attribute-value":"2", "operator": "=", "unit": ""},
                {"hpa-attribute-key": "numaMem-0", "hpa-attribute-value": "2048", "operator": "=", "unit": "MB"}
                {"hpa-attribute-key": "numaCpu-1", "hpa-attribute-value":"4", "operator": "=", "unit": ""},
                {"hpa-attribute-key": "numaMem-1", "value": "4096", "operator": "=", "unit": "MB"}
              ]
            },
            {
              "hpa-feature" : "basicCapabilities",
              "mandatory" : "True",
              "architecture": "generic",
              "hpa-version": "v1",
              "hpa-feature-attributes": [
                {"hpa-attribute-key": "numVirtualCpu", "hpa-attribute-value": "6", "operator": "=", "unit": ""},
                {"hpa-attribute-key": "virtualMemSize", "hpa-attribute-value":"6", "operator": "=", "unit": "GB"}
              ]
            },
            {
              "hpa-feature" : "hugePages",
              "mandatory" : "False",
              "score" : "7",
              "architecture": "generic",
              "hpa-version": "v1",
              "hpa-feature-attributes": [
                 {"hpa-attribute-key": "memoryPageSize", "hpa-attribute-value": "<MEMORYPAGESIZE>", "operator": "=", "unit": ""}
              ]
            }
          ] 
        }
      ]
    }
}

The fields in this example policy are typically generated from a TOSCA service model specified by VNF vendors or service designers. This policy cannot be changed during the life-cycle of a service.



CPUTHREADPOLICY = prefer, isolate, require

CPUPOLICY = shared, dedicated

PCIETYPEVALUE: SRIOV, PCI-PASSTHROUGH

CPUINST = aes, avx, sha_ni, mpx, adcx, mpx, pclmulqdq, rdrand,sse, etc

MEMORYPAGESIZE = 4KB (unit=KB), 2MB (unit=MB), 1GB(unit=GB), ANY, Other explicit Page size

Distance Policy Example 
{
  "service": "distancePolicy",
  "policyName": "oofBeijing.distancePolicy_vGMuxInfra",
  "description": "Distance Policy for vGMuxInfra",
  "templateVersion": "0.0.1",
  "version": "oofBeijing",
  "priority": "3",
  "riskType": "test",
  "riskLevel": "2",
  "guard": "False",
  "content": {
    "distanceProperties": {
      "locationInfo": customer_location",
      "distance": { "value": "500", "operator": "<", "unit": "km" }
    },
    "resources": ["vGMuxInfra", "vG"],
    "applicableResources": "any",
    "identity": "distance-vGMuxInfra",
    "policyScope": ["vCPE", "US", "INTERNATIONAL", "ip", "vGMuxInfra"],
    "policyType": "distancePolicy"
  }
}

The fields in this example policy are typically generated from a TOSCA service model specified by VNF vendors or service designers. However, the policy can be updated over time by operators.

HPA Basic Capabilities Policy Example 
{
    "hpa-feature" : "basicCapabilities",
    "mandatory" : "False",
    "score" : "5",
    "architecture": "generic",
    "hpa-version": "v1",
    "hpa-feature-attributes": [
       {"hpa-attribute-key": "numVirtualCpu", "hpa-attribute-value": "6", "operator": "=", "unit": ""},
       {"hpa-attribute-key": "virtualMemSize", "hpa-attribute-value":"6", "operator": "=", "unit": "GB"}
    ]
}

The fields in this example policy are typically generated from a TOSCA service model specified by VNF vendors or service designers. This policy cannot be changed during the life-cycle of a service.

HPA OVS DPDK Policy Example 
{
    "hpa-feature" : "ovsDpdk",
    "mandatory" : "False",
    "score" : "5",
    "architecture": "INTEL-64",
    "hpa-version": "v1",
    "hpa-feature-attributes": [
      {"hpa-attribute-key":"dataProcessingAccelerationLibrary", "hpa-attribute-value":"ovsDpdk_version", "operator": "=", "unit":""}
     ]
}

The fields in this example policy are typically generated from a TOSCA service model specified by VNF vendors or service designers. This policy cannot be changed during the life-cycle of a service.

For this policy others architectures are also applicable.

HPA CPU Pinning Policy Example 
{
   "hpa-feature" : "cpuPinning",
   "mandatory" : "False",
   "score" : "5",
   "architecture": "generic",
   "hpa-version": "v1",
   "hpa-feature-attributes": [
     {"hpa-attribute-key":"logicalCpuThreadPinningPolicy", "hpa-attribute-value":"<CPUTHREADPOLICY>", "operator": "=", "unit":""},
     {"hpa-attribute-key":"logicalCpuPinningPolicy", "hpa-attribute-value": "<CPUPOLICY>","operator": "=", "unit":""},
    ]
}

The fields in this example policy are typically generated from a TOSCA service model specified by VNF vendors or service designers. This policy cannot be changed during the life-cycle of a service.


CPUTHREADPOLICY = prefer, isolate, require
CPUPOLICY = shared, dedicated


HPA NUMA Policy Example 
{
    "hpa-feature" : "numa",
    "mandatory" : "False",
    "score" : "5",
    "architecture": "generic",
    "hpa-version": "v1",
    "hpa-feature-attributes": [
       {"hpa-attribute-key": "numaNodes", "hpa-attribute-value": "2", "operator": "=", "unit": ""},
       {"hpa-attribute-key": "numaCpu-0", "hpa-attribute-value":"2", "operator": "=", "unit": ""},
       {"hpa-attribute-key": "numaMem-0", "hpa-attribute-value": "2048", "operator": "=", "unit": "MB"},
       {"hpa-attribute-key": "numaCpu-1", "hpa-attribute-value":"4", "operator": "=", "unit": ""},
       {"hpa-attribute-key": "numaMem-1", "hpa-attribute-value": "4096", "operator": "=", "unit": "MB"}
    ]
}

The fields in this example policy are typically generated from a TOSCA service model specified by VNF vendors or service designers. This policy cannot be changed during the life-cycle of a service.

HPA CPU Topology Policy Example 
{
   "hpa-feature" : "cpuTopology",
   "mandatory" : "False",
   "score" : "5",
   "architecture": "generic",
   "hpa-version": "v1",
   "hpa-feature-attributes": [
      {"hpa-attribute-key":"numCpuSockets", "hpa-attribute-value": "2","operator": ">=", "unit": ""},
      {"hpa-attribute-key":"numCpuSockets", "hpa-attribute-value": "4","operator": "<=", "unit": ""},
      {"hpa-attribute-key":"numCpuCores", "hpa-attribute-value": "2", "operator":">=", "unit": ""},
      {"hpa-attribute-key":"numCpuCores", "hpa-attribute-value": "4", "operator":"<=", "unit": ""},
      {"hpa-attribute-key":"numCpuThreads", "hpa-attribute-value": "4", "operator":">=", "unit": ""},
      {"hpa-attribute-key":"numCpuThreads", "hpa-attribute-value": "8", "operator":"<=", "unit": ""}
   ]
}

The fields in this example policy are typically generated from a TOSCA service model specified by VNF vendors or service designers. This policy cannot be changed during the life-cycle of a service.

Affinity Policy Example 
{
    "service": "affinityPolicy",
    "policyName": "oofBeijing.affinityPolicy_vcpe",
    "description": "Affinity policy for vCPE",
    "templateVersion": "1702.03",
    "version": "oofBeijing",
    "priority": "5",
    "riskType": "test",
    "riskLevel": "2",
    "guard": "False",
    "content": {
        "identity": "affinity_vCPE",
        "policyScope": ["vCPE", "US", "INTERNATIONAL", "ip", "vGMuxInfra"],
        "affinityProperties": {
            "qualifier": "different",
            "category": "complex"
        },
        "policyType": "affinityPolicy",
        "resources": ["vGMuxInfra", "vG"],
        "applicableResources": "all"
    }
}

The fields in this example policy are typically generated from a TOSCA service model specified by VNF vendors or service designers. This policy cannot be changed during the life-cycle of a service.

Capacity Policy Example 
{
    "service": "capacityPolicy",
    "policyName": "oofBeijing.capacityPolicy_vGMuxInfra",
    "description": "Capacity policy for vGMuxInfra",
    "templateVersion": "1702.03",
    "version": "oofBeijing",
    "priority": "5",
    "riskType": "test",
    "riskLevel": "2",
    "guard": "False",
    "content": {
        "identity": "capacity_vGMuxInfra",
        "policyScope": ["vCPE", "US", "INTERNATIONAL", "ip", "vGMuxInfra"],
		"controller": "multicloud",
        "capacityProperties": {
            "cpu": {"value": 2, "operator": ">"},
            "memory": {"value": 4, "operator": ">", "unit": "GB"}
			"storage": {"value": 80, "operator": ">", "unit": "GB"}
        },
        "policyType": "vim_fit",
        "resources": ["vGMuxInfra"],
        "applicableResources": "any"
    }
}

The fields in this example policy are typically generated from a TOSCA service model specified by VNF vendors or service designers. This policy cannot be changed during the life-cycle of a service.

Min Guarantee Policy Example 
{
    "service": "minGuaranteePolicy",
    "policyName": "oofBeijing.minGuaranee_vGMuxInfra",
    "description": "Min guarantee policy for vGMuxInfra",
    "templateVersion": "1702.03",
    "version": "oofBeijing",
    "priority": "5",
    "riskType": "test",
    "riskLevel": "2",
    "guard": "False",
    "content": {
        "identity": "minGuarantee_vGMuxInfra",
        "policyScope": ["vCPE", "US", "INTERNATIONAL", "ip", "vGMuxInfra"],
        "minGuaranteeProperty": {
            "cpu": "true",
            "memory": "false",
        },
        "type": "minGuaranteePolicy",
        "resources": ["vGMuxInfra"],
		"applicableResources": "any"
    }
}

The fields in this example policy are typically generated from a TOSCA service model specified by VNF vendors or service designers. This policy cannot be changed during the life-cycle of a service. A min-guarantee policy can be specified using the HPA policy model.

Optimization Policy Example 
{
    "service": "PlacementOptimizationPolicy",
    "policyName": "oofBeijing.PlacementOptimizationPolicy_vGMuxInfra",
    "description": "Placement Optimization Policy for vGMuxInfra",
    "templateVersion": "1702.03",
    "version": "oofBeijing",
    "priority": "5",
    "riskType": "test",
    "riskLevel": "3",
    "guard": "False",
    "content": {
        "objectiveParameter": {
            "parameterAttributes": [
                {
                    "resources": ["vGMuxInfra"],
                    "customerLocationInfo": "customer_loc",
                    "parameter": "distance",
                    "weight": "1",
                    "operator": "product"=
                },
                {
                    "resources": ["vG"],
                    "customerLocationInfo": "customer_loc",
                    "parameter": "distance",
                    "weight": "1",
                    "operator": "product"
                }
            ],
            "operator": "sum"
        },
        "identity": "optimization",
        "policyScope": ["vCPE", "US", "INTERNATIONAL", "ip", "vGMuxInfra"],
        "policyType": "placementOptimization",
        "objective": "minimize"
    }
}

The fields in this example policy are typically generated from a TOSCA service model specified by VNF vendors or service designers. This policy cannot be changed during the life-cycle of a service.



HPA PCIe Policy Example 
{
    "hpa-feature" : "pcie",
    "mandatory" : "False",
    "score" : "5",
    "architecture": "generic",
    "hpa-version": "v1",
    "hpa-feature-attributes": [
      {"hpa-attribute-key": "pciCount", "hpa-attribute-value": "2", "operator": "=", "unit": ""},
      {"hpa-attribute-key": "pciVendorId", "hpa-attribute-value":"8086", "operator": "=", "unit": ""},
	  {"hpa-attribute-key": "pciDeviceId", "hpa-attribute-value": "2", "operator": "=", "unit": ""} 
      {"hpa-attribute-key": "functionType", "hpa-attribute-value": "<PCIETYPEVALUE>","operator": "=", "unit": ""} 
     ]
}

PCIETYPEVALUE: SRIOV, PCI-PASSTHROUGH

HPA Local Storage Policy Example 
{
    "hpa-feature" : "localStorage",
    "mandatory" : "False",
    "score" : "5",
    "architecture": "generic",
    "hpa-version": "v1",
    "hpa-feature-attributes": [
       {"hpa-attribute-key": "diskSize", "hpa-attribute-value": "2", "operator": "=", "unit": "GB"},   
       {"hpa-attribute-key": "ephemeralDiskSize", "hpa-attribute-value": "2", "operator": "=", "unit": "GB"},
	   {"hpa-attribute-key": "swapMemSize", "hpa-attribute-value":"16", "operator": "=", "unit": "MB"},
     ]
}

The fields in this example policy are typically generated from a TOSCA service model specified by VNF vendors or service designers. This policy cannot be changed during the life-cycle of a service.

HPA CPU Instruction Set Extensions Policy Example 
{
    "hpa-feature" : "cpuInstructionSetExtensions",
    "mandatory" : "False",
    "score" : "5",
    "architecture": "INTEL-64",
    "hpa-version": "v1",
    "hpa-feature-attributes": [
      {"hpa-attribute-key":"instructionSetExtensions", "hpa-attribute-value":["<CPUINST>", "<CPUINST>"] "operator": "ALL", "unit":""}
     ]
}
instructionSetExtensions attribute has a list of all instruction set extensions required. 
CPUINST = aes, avx, sha_ni, mpx, adcx, mpx, pclmulqdq, rdrand,sse, etc
HPA Huge Pages Policy Example 
{
    "hpa-feature" : "hugePages",
    "mandatory" : "False",
    "score" : "5",
    "architecture": "generic",
    "hpa-version": "v1",
    "hpa-feature-attributes": [
      {"hpa-attribute-key": "memoryPageSize", "hpa-attribute-value": "<MEMORYPAGESIZE>", "operator": "=", "unit": ""}
    ]
}

MEMORYPAGESIZE = 4KB (unit=KB), 2MB (unit=MB), 1GB(unit GB), ANY, Other explicit Page size

VNF Policy Example 
{
    "service": "vnfPolicy",
    "policyName": "oofBeijing.vnfPolicy_vGMuxInfra",
    "description": "vnfPolicy",
    "templateVersion": "1702.03",
    "version": "oofBeijing",
    "priority": "6",
    "riskType": "test",
    "riskLevel": "3",
    "guard": "False",
    "content": {
        "identity": "vnf_vGMuxInfra",
        "policyScope": ["vCPE", "INTERNATIONAL", "ip", "vGMuxInfra"],
        "policyType": "vnf_policy",
        "resources": ["vGMuxInfra"],
        "applicableResources": "any",
        "vnfProperties": [
            {
                "inventoryProvider": "aai",
                "serviceType": "",
                "inventoryType": "cloudRegionId",
                "customerId": ""
            },
            {
                "inventoryProvider": "multicloud",
                "serviceType": "HNGATEWAY",
                "inventoryType": "serviceInstanceId",
                "customerId": "21014aa2-526b-11e6-beb8-9e71128cae77"
            }
        ]
    }
}

VNF policy captures the location of inventories and customer information.

Subscriber Role Policy Example 
{
 "service": "SubscriberPolicy",
 "policyName": "oofBeijing.SubscriberPolicy_v1",
 "description": "Subscriber Policy",
 "templateVersion": "0.0.1",
 "version": "oofBeijing",
 "priority": "1",
 "riskType": "test",
 "riskLevel": "3",
 "guard": "False",
 "content": {
        "identity": "subscriber",
        "policyScope": ["vCPE", "subscriber_x", "subscriber_y"],
        "properties": {
                "subscriberName": ["subscriber_x", "subscriber_y"],
                "subscriberRole": ["Test"],
                "provStatus": ["CAPPED"]
        },
        "policyType": "SubscriberPolicy"
 }
}

Subscriber role policy to capture the role of a subscriber and related provisioning states.

OOF-CMSO Policies

TBD

Modes for Fetching Policies

OOF can fetch optimzation policies using the getConfig API of the policy system. The policies can be searched and filtered in two different modes; by-name and by-scope from the policy system.

By-name: OOF can send an explicite policy name or a regular expression matching a set of policy names as a part of the getConfig API payload. In return, OOF expects to receive a specific policy or a set of policies with name matching to the regular expression.

By-scope: A scope is the domain to which a policy is applicable. Scope information can be captured as a set of attribute-value pairs, which can be sent as a part of the getConfig API payload. In response, the policy system is expected to return a set of policies with the matching attribute-value pairs. A policy can only be included in the response if all the matching attribute-value pairs exist.

OOF can requerst prioritization by enabling a prioritization flag in the getConfig API call to the policy system, and expects to receive a single policy with the highest priority policy among the set of policies meeting the search criteria.

TOSCA Policy Models

The following TOSCA policy models need to be uploaded as a dictionary during the deployment-time of an optimization application. Currently, the model uploading porcess is manual since the policy system does not offer an interface to upload models programatically. Once the models are uploaded, policy templates are created in the policy portal/GUI using which optimization policies can be created. Alternatively, the policy system offers CRUD REST APIs using which the policies can be managed by the application.

HAS Policies for Testing

Affinity_vCPE_1.jsonCapacity_vG_1.jsonCapacity_vGMuxInfra.jsonDistance_vG_1.jsonDistance_vGMuxInfra_1.jsonhpa_policy_vG_1.jsonhpa_policy_vGMuxInfra_1.jsonPlacement_Optimization_1.jsonQueryPolicy_vCPE.jsonsubscriber_policy.jsonvnfPolicy_vG.jsonvnfPolicy_vGMuxInfra.json


  • No labels

39 Comments

  1. Shankaranarayanan Puzhavakath Narayanan

    Since policy specification and retrieval is a critical feature provided by OSDF, can we create move this page under the OSDF umbrella - Optimization Design Framework (OSDF). I'm hoping it will help associate the APIs with the corresponding repo.   

    1. Sastry Isukapalli

      Done. Moved the page.

  2. Shankaranarayanan Puzhavakath Narayanan

    Also, please create a cross reference link for the CMSO policy API and HAS policy API in the respective pages (CMSO (R2) Release Planning,OOF-Policy Interaction in R2) 

    1. Sastry Isukapalli

      Would you please create yourself? I created anchors on this page (e.g. OOF-HAS Policies, OOF-CMSO Policies, etc., that should be searchable)

  3. Srinivasa Addepalli

    Ankitkumar Patel, Shankaranarayanan Puzhavakath Narayanan, Dileep Ranganathan, Alexander Vul, Adolfo Perez-Duran, Sastry Isukapalli

    Hi,

    Looks like policy definition is moved to this page.  I have put my comments earlier in OOF-Policy Interaction in R2. Please check.

    Ankit,  Thank you for taking HPA example and creating policy.  

    In summary, there are two differences.

    1.  In the examples you have show cases, each HPA feature is described in different policies.  Since, one VNFD requires multiple HPA features, we felt that it is simple to put all HPA features required by one VNF type in one policy.  Can we make policy language take multiple HPA features in one policy object?
    2. As mentioned in the other page (OOF-Policy Interaction in R2),  extensibility is very important to us.  Every time new capabilities are realized in remote sites,  we would like to have that feature available as fast as possible in ONAP. Hence, we want to ensure that there are no changes (other than the Multi-Cloud plugin) in any projects.   Please consider this in the policy language.

    Srini

    1. Srinivasa Addepalli

      Ankitkumar Patel

      Hi Ankit,

      On extensibility :  I am thinking little bit more on this.  As long as names are not hardcoded in the code, but learnt from the policy, I guess it is extensible.  Can you please confirm this.  If so,  item 2 is no longer a problem.  But, we really would like all HPA features for a given VNF be in one JSON document.  Please do let us know whether that is possible.  

      Thanks

      Srini

      1. Ankitkumar Patel

        Hi Srini,

        Should all HPA features be captured in a single policy or broken down into multiple policies depends on one fundamental question; Are these features applicable to all VNFs that OOF-HAS needs to support over time? If the answer is no, it's good idea to split them into multiple policies. Breaking the features into multiple policies may give us flexibility in accessing and managing them for different VNFs.

        On the extensibility aspects, we can model the HPA policies using generic key-value pairs. Even though the policy platform does not support (1) tooltip capability and (2) dynamic selection of domain values (as I have highlighted in my pervious response), extensible HPA policy models still makes sense for R2 since the HPA policies will be auto-populated by a system and not a human being. 

        1. Alexander Vul

          Please see my comments below. To summarize...

          • ideally, policy format would identical to TOSCA HPA capability specification format.
          • Please use one policy per capability requirement.

        2. Srinivasa Addepalli

          Hi Ankit, Ankitkumar Patel, Dileep Ranganathan, Alexander Vul, Adolfo Perez-Duran

          All HPA features are applicable for all VNFs.  But, with two differences:

          • All VNFDs don't use all HPA features.
          • For HPA feature they use,   the HPA attribute values (HPA feature capability) for each feature differ from one VNF to another.

          I felt that having one policy record for each VNF representing all HPA capabilities may be good for following reasons:

          • Number of policy records is small and policy lookup performance is better.
          • If some reason, manual authoring is required (say some VNFD is not adding HPA capabilities via TOSCA), then it becomes easy to create one policy record instead of multiple policy records by operator.
          • It may simplify the conversion logic in policy engine as one VNFD becomes one policy record.

          If there are any code changes required to support multiple HPA capabilities in one policy, then we can go with multiple policy records for Beijing release and think about one policy record for one VNFD in future releases. 

          So, the question:  Is there any expectation in the OOF code that a record has only one capability? Or does OOF code support list of capabilities in one policy record?

          BTW, I checked your HPA examples. they are pretty well captured.  Some HPA capability requirements by VNF are optional or mandatory. I see lot of attributes. Is one of them represent mandatory/optional?  if it is optional, normally there is a need for some kind of weight/score.  Can that be captured in your examples?

  4. Srinivasa Addepalli

    Ankitkumar Patel, Shankar Satyanarayanan, Dileep Ranganathan, Alexander Vul, Adolfo Perez-Duran, Sastry Isukapalli

    Based on explanation on this page,  the role of POLICY engine is really store and retrieve. Right?  Policy Engine does not need to make any decisions.  All decision making is part of OOF logic.  I am okay with it, but wanted to get the confirmation on this understanding.

    1. Sastry Isukapalli

      Confirming that it is the case (currently almost all the policies we are using). The minor exception is the policy prioritization when multiple policies of the same name are created with different priorities (the policy platform handles that prioritization).

  5. Srinivasa Addepalli

    Ankitkumar Patel, Shankaranarayanan Puzhavakath Narayanan, Dileep Ranganathan, Alexander Vul, Adolfo Perez-Duran, Sastry Isukapalli

    Hi,

    Is there JSON Schema being defined for these policies? 

    JSON schema can do some syntax checking.  But, is there any ability in policy engine to add some validation plugin to ensure that the semantics of the policy information is good?  it is good if the validation plugin runs whenever policy object is added to policy repository.  That way, errors can be returned at early stages.

    Srini

    1. Sastry Isukapalli

      We have a python module inside the OSDF code that validates based on the underlying model. We have been using that for larger request validation (e.g. incoming request from SO).

      For the case of policies, since each policy model will have minor variations, we may have to write separate schemas for each one. For simple polices that we are using so far, it didn't make a major difference. My initial impression is that the we should develop validation models for policy models that are used more frequently. It is something definitely of interest.

    2. Ankitkumar Patel

      Currently the policy system supports TOSCA and EMF modeling languages to model a policy and both of these language specifications have enough hooks to specify the validation requirements. So, policy validation happens during while a policy is being specified/created in the policy system. We can also conduct additional validations within OOF/OSDF as Sastry has suggested.

  6. Alexander Vul

    Folks,


    We need to tease apart HPA policies from the VNFD specified VNF capability requirements. They are not the same. They will not be in the same format. VNF capability requirements will be specified following TOSCA conventions. Policied will need to be derived from this format. We will use a external schema tor syntactic validation and parsing of VNFD supplied HPA capability requirements.

    In the VNFD, HPA capability requirements are specified as "TOSCA capabilities" associated with multiple TOSCA nodes. I would strongly recommend that we define a separate policy for each HPA capability requirement. This way we are free to evolve the HPA space without significant impact on the OOF space.

    If at all possible, I would also suggest that the policy format be identical to the TOSCA HPA capability specification format... 


    Thanks,

    Alex



    1. Ankitkumar Patel

      Hi Alex,

      Currently, I am referring the AAI schema (https://wiki.onap.org/plugins/servlet/mobile?contentId=25428337#content/view/20873389) to model HPA policies since use of the same structure and naming conventions as AAI can help HAS to build AAI queries. However, it makes sense to match the TOSCA HPA capability specification format since the target users are service designers and operators. Would you please give us references where TOSCA specification for HPA is documented?

      Thanks,

      Ankit

  7. Srinivasa Addepalli

    Meeting minutes on HPA policy review (on last Thursday)

    Hi Ritu Sood and Dileep Ranganathan

    1. Extensible HPA Hyper-Threading Policy Example :  This needs to be removed as these capabilities are spread across other policies such as "CPU Topology", "Capacity Policy Example" and "HPA Generic Attributes example".

    2. "HPA AES Policy" example and "HPA AVX Example":  We thought that instead of showcasing every instruction extension as a separate policy, we also provide a policy example where multiple instructions can be specified.  As as example
                {"attribute":"hpaFeature", "value": "cpuInstructionExtensions","operator": "=", "unit":""},
                {"attribute":"architecture", "value": "INTELx64","operator": "=", "unit": ""},
                {"attribute":"mandatory", "value": "true","operator": "=", "unit":""},
                {"attribute":"score", "value": "4", "operator":"=", "unit": ""},
                {"attribute":"instructionSetExtensions", "value":["avx", "aes"], "operator": "all", "unit":""},

    3. Renaming of "HPA Capacity Example" to "HPA Basic capabilities":  Just a name change.

    4. HPA Generic Attributes Policy : Since vCPus and memory size is taken care elsewhere, these attributes need to be removed from this policy example. Also,it is good to rename this as 'HPA local storage Example"?

    5. HPA OVS_DPDK Policy Example : We thought we will change from library_version to something else for readability. Is it "ovs_dpdk_version"?

    6. HPA NUMA example :  Making changes to explicitly give number of CPUs for each node and memory size for each node.  Also, to be consistent across examples,  please ensure that cpus and memory added across all the numa nodes in this example add up the vCPUS and memory mentioned in "HPA Basic Capabilities" example.

    7. Adding more examples related to 

      1. "RDT L3 Cache size" and "RDT MBT".

      2. NFVI real time OS.

      3. Huge pages.

      4. CPU & Thread pinning example

    Please add if I missed any.
    Srini

    1. Ankitkumar Patel

      Srinivasa Addepalli and Ritu Sood:

      As I understood more on the HAP requirements, I found that the requirements are correlated through a VNF. Please correct me if I am mistaken. In this case, it won't be convenient from the policy specification and management aspects to split the requirements into multiple independent policies. Thus, the modeling proposal made by Srini makes sense now. Here is the example of a policy if we combine multiple HPA requirements related to a VNF. Please let me know if you agree/disagree so that we can update the models and related examples.

      {
          "service": "hpaOvsDpdkPolicy",
          "policyName": "oofBeijing.hpaOvsDpdkPolicy_vGMuxInfra",
          "description": "HPA OVS DPDK policy for vGMuxInfra",
          "templateVersion": "0.0.1",
          "version": "oofBeijing",
          "priority": "3",
          "riskType": "test",
          "riskLevel": "2",
          "guard": "False",
          "content": {
               "resources": "vGMuxInfra",

               "flavorFeatures": [

                   {

                        "flavorLabel": "vm1",
                        "flavorProperties":[
                             {
                                "hpa_feature" : "cpuTopology",
                                "mandatory" : "yes",
                                "architecture": "intel64",

                                "attributes": [
                                    {"attribute":"numCpuSockets", "values": "2","operator": ">=", "unit": ""},
                                    {"attribute":"numCpuSockets", "values": "4","operator": "<=", "unit": ""},
                                    {"attribute":"numCpuCores", "value": "2", "operator":">=", "unit": ""},
                                    {"attribute":"numCpuCores", "value": "4", "operator":"<=", "unit": ""},
                                    {"attribute":"numCpuThreads", "value": "4", "operator":">=", "unit": ""},
                                    {"attribute":"numCpuThreads", "value": "8", "operator":"<=", "unit": ""}
                                ]
                            },
                            {
                              "hpa_feature" : "basicCapabilities",
                              "mandatory" : "false",
                              "architecture": "generic",
                              "attributes": [
                                  {"attribute": "numVirtualCpu", "value": "6", "operator": "=", "unit": ""},
                                  {"attribute": "virtualMemSize", "value":"6", "operator": "=", "unit": "GB"}
                               ]
                            }
                       ] 

                 },

                {

                        "flavorLabel": "vm2",
                        "flavorProperties":[
                             {
                                "hpa_feature" : "cpuTopology",
                                "mandatory" : "yes",
                                "architecture": "intel64",

                                "attributes": [
                                    {"attribute":"numCpuSockets", "values": "2","operator": ">=", "unit": ""},
                                    {"attribute":"numCpuSockets", "values": "4","operator": "<=", "unit": ""},
                                    {"attribute":"numCpuCores", "value": "2", "operator":">=", "unit": ""},
                                    {"attribute":"numCpuCores", "value": "4", "operator":"<=", "unit": ""},
                                    {"attribute":"numCpuThreads", "value": "4", "operator":">=", "unit": ""},
                                    {"attribute":"numCpuThreads", "value": "8", "operator":"<=", "unit": ""}
                                ]
                            },
                            {
                              "hpa_feature" : "basicCapabilities",
                              "mandatory" : "false",
                              "architecture": "generic",
                              "attributes": [
                                  {"attribute": "numVirtualCpu", "value": "6", "operator": "=", "unit": ""},
                                  {"attribute": "virtualMemSize", "value":"6", "operator": "=", "unit": "GB"}
                               ]
                            } 
                       ]

                 } 

              ]

          }
          "identity": "hpaPolicy_vGMuxInfra",
          "policyScope": ["vCPE", "US", "INTERNATIONAL", "ip", "vGMuxInfra"],
          "type": "hpaOvsDpdkPolicy",
          "resourceInstanceType": ["vGMuxInfra"]
      }

      1. Ritu Sood

        This is good. One comment where will the flavor label go. Will be be at the hpaFeature level? Flavor label is needed for per VM distinction. 

        1. Ankitkumar Patel

          Here, flavor-label refers to a TOSCA attribute that uniquely identifies a VNF. We can change the naming of this attribute later. The flavor label should be at the same level as resource/VNF, shouldn't it?

          1. Ritu Sood

            Since each VNF can have multiple VMs/VFModules, in my understanding flavor label is at the level of VM so the OOF can select flavor per VM

            1. Ankitkumar Patel

              Makes sense! Are you suggesting to capture flavorName at the same level as hpa_feature?

              1. Srinivasa Addepalli

                Thank you for flexibility to add multiple HPA constraints in one policy.

                Normally a VNF contains multiple VDUs and each VDU asks for multiple HPA feature constraints.

                With this new proposal, instead of each VDU HW requirements in multiple policies,  now there is only one policy for each VDU.

                So, a policy will have flavor-label at the policy level. I think Ritu is also suggesting that flavor-label to be included at the policy level.

                Srini



                1. Ankitkumar Patel

                  Srini: I don't understand what you mean by policy level. Can you please review the example and update it?

                  1. Srinivasa Addepalli

                    I am okay with either approach.

                    I feel that we made big swing where one policy represents HPA requirements for all VMs of VNF.  I was suggesting one policy per VM in VNF.

                    I am okay with this too.  @Ritu?

                    1. Ritu Sood

                      We had a chance to speak to Ankit today. As he explained all the ONAP components work at the VNF level and that is the reason that this structure needs to be at the VNF level. This version of the structure looks good to me.

                      1. Srinivasa Addepalli

                        Ok. I am okay with this structure too as multiple HPA capabilities can be represented for each.

                        Ankitkumar Patel,   We are all good.  Thank you.

        2. Adolfo Perez-Duran

          This is much better.  It decouples HPA features/capabilities from policy properties.

          These are specific examples of how to use the data structure. It seems to me that we are going to need a schema so that we can accommodate different data types.

          Two examples.

          One. The cpu architecture attribute could have one of several distinct values, such as aarch64, intel64 (amd64) or ppc64le. This attribute requires an enum type.

          Two. cpuInstructionSetExtensions has a discrete and well defined number of values for this attribute. This attribute requires a collection type.

          1. Srinivasa Addepalli


            Ankitkumar Patel, Ritu Sood, Dileep Ranganathan, Shankaranarayanan Puzhavakath Narayanan please validate.

            My understanding is this -  

            Operator attribute value defines the type of value.

            If operator is =, >, <, >=, <=, then the value of value attribute is assumed to be integer.

            If operator is 'any' or 'all', then the value of value attribute is assumed to be pcre or string.

            If the value of value attribute has values enclosed in square brackets, multiple values are comma separated.

            1. Ankitkumar Patel

              The policy system validates a policy based the policy model prior to storing it in the policy repo. The validation is done using the type field for an attribute in a model. Since the HPA policy is modeled using name-value pairs (e.g. featureAttributes) to gain extensibility, the type of 'value/s' in the HPA model is indeterministic, and thus, we have to model the 'value/s' field as String. Currently, the policy system does not support dynamic validation on-the-fly based on the configuration of other attributes.

  8. Srinivasa Addepalli

    Ankit,

    Policy template you have created is very good.  I just added 'score' in there.

    Srini

  9. Ankitkumar Patel

    Ritu Sood, Srinivasa Addepalli, and ramki krishnan

    You mentioned that the min_guarantee policy can be captured using the HPA policy model. Can you please update the min_guarantee policy example here?

    -Ankit

  10. Claude Noshpitz

    This is an excellent discussion, which I unfortunately have stumbled upon a bit late :-/

    Please forgive my impertinence in posing what might be some completely out-of-scope questions (and feel free to redirect as appropriate)...

    It would appear that the intent here is for OOF Policies to involve runtime capabilities, at the resource level, which may be specific to each potential deployment environment.  There's some level of indirection offered by HPA, but it seems like there's a lack of standardization across cloud platforms on how such metadata are to be populated and exposed.  This becomes increasingly ambiguous as we move to commercial Cloud Service Provider platforms, but seems likely to be problematic even among the various existing and planned variations on AIC/AEC. 

    Likewise, there would appear to be some crossing of separation-of-concerns boundaries when a logically centralized service-level policy engine needs to make decisions based on intimate knowledge of available capacity and detailed capabilities of an underlying deployment platform.

    Given that "...the homing service finds homing solutions based on the evaluation of the received HPA policies and returns the solutions to SO", to what extent are those homing solutions based on deep knowledge about the target platform?  How does this evaluation work unambiguously across such platforms?  In third-party or multiple- version cloud environments?


    Thanks!


    --Claude

    1. Shankaranarayanan Puzhavakath Narayanan

      Claude Noshpitz, 

      Thanks for your thoughts and questions on this! Can you please elaborate a bit on lack of standardization across cloud platforms - is your concern specific to HPA or is this broader than that ?

      The crossing of boundaries between service-level and platform-level entities has often been a concern to me as well. In fact, we have been driving the homing to not be intricately dependent on the detailed capacity/capability information, but use them on an opportunistic basis when available on Operator-owned clouds. Further, we have been discussing about having MultiCloud providing a vim_fit interface, that takes as input such detailed platform-level requirements of the service (and VNFs), and returns the VIM instances that can accommodate these requests. In fact, the check_vim_capacity() API provided by MultiCloud in R2 was to precisely honor this separation of concerns. More details on the related discussion can be found here: OOF - MultiCloud interaction in R2 - apologies if the document is not the easiest to read as it seems more like documented conversations.

      That said, in R2, the HPA is expected to be a part of the VIM capability that is exported via AAI (Persistence of HPA related information in AAI). There is also an interesting discussion on how homing returns the flavor information in R2 (https://lists.onap.org/pipermail/onap-oof/2018-February/000042.html). 

      Thanks for your questions, and we'd love to hear your thoughts on this! 

  11. libo zhu

    hello, Ankit, 

                  the HPA policy template is also based on TOSCA standard, right? is there any concern or dependency about the  link Supported HPA Capability Requirements(DRAFT)?

    since from the specified schema, they are different.

    1. Ankitkumar Patel

      Hi Libo,

      The HPA policy is modeled such that HPA capability requirements can be captured as name-value pairs. This model brings two benefits; (1) new requirements can be captures without updating the model in future, and (2) the auto-generation of HPA policies becomes simpler since the policy system does not need to understand the structure and semantics of the HPA model. The optimization policy models are created using the TOSCA specs defined by the policy team, which are customized to meet the policy template rendering requirements. In the wiki page you referred, the schema is the flat structure of HPA attribute-value pairs which can easily fit the model. Please let me know if I misunderstood you.

      Ankit

      1. libo zhu

        hello, Ankit,

                  since the policy Dictionary GUI can't tell TOSCA format, just accept .csv file. per your description "The optimization policy models are created using the TOSCA specs defined by the policy team, which are customized to meet the policy template rendering requirements", then how could user leverage/use your provided HPA Policy TOSCA format yml file? by sql inject or another method?

                   please help and provide the specified steps. thanks 

  12. Ankitkumar Patel

    Shankar Satyanarayanan:

    It looks like the following structure in the conductor template should be populated from the capacity policy, and so, I updated the capacity policy model and example. Can you please confirm the model/example captured all the required information for the HAS optimization?

    - check_cloud_capacity:
        type: vim_fit
        demands:
        - vG
        properties:
          controller: multicloud
          request:
            vCPU: 10
            Memory:
              quantity:
                get_param: REQUIRED_MEM
              unit: GB
            Storage:
              quantity:
                get_param: REQUIRED_DISK
              unit: GB

    Ankit

    1. Ankitkumar Patel

      Hi Shankaranarayanan Puzhavakath Narayanan,

      We cannot model a JSON blob in TOSCA and thus templates cannot be rendered in the policy portal. For the time being, I am planning to model it as JSON string. 

      Ankit