HPA VF-C External API Interaction for Casablanca

SDC

Supported HPA Capability Requirements(DRAFT)#LogicalNodei/ORequirements is referred.

SDC will provide below HPA information to VF-C

...

Code Block

language	js
title	VFC-OOF API
linenumbers	true
collapse	true

{
  "requestInfo": {
    "transactionId": "2441780a-2710-4169-91ee-a9f52a705bb3 //UUID",
    "requestId": "2441780a-2710-4169-91ee-a9f52a705bb3 //UUID",
    "callbackUrl": "<callback URL from VFC>",
    "sourceId": "vfc",
    "requestType": "create",
    "numSolutions": 1,
    "optimizers": [
      "placement"
    ],
    "timeout": 600
  },
  "placementInfo": {
    "placementDemands": [
      {
        "resourceModuleName": "vBRG //<VNF name from CSAR>",
        "serviceResourceId": "<vnfInstanceId used inside VFC>",
        "resourceModelInfo": {
          "modelInvariantId": "no-resourceModelInvariantId",
          "modelVersionId": "no-resourceModelVersionId"
        }
         }
        ]
      },
      "serviceInfo":
      {
 
      "serviceInstanceId": "9fd24064-a335-478c-bbb0-3b71b7fbc55f",
        "serviceName": "vcpe",
  
     "modelInfo": {
   
      "modelInvariantId": "31390ef2-94a9-4cef-a09a-08f7d66540c9 //Id get from CSAR",
   
      "modelVersionId": "1a32426f-3616-47d0-96eb-b20cc7fff9be //Id get from CSAR"
  
     }
 
    }
      }

OOF retrieve the requirements(policies) for that service/VNF inside Policy

...

Code Block

language	js
title	OOF retrieve HPA policies for VFC
linenumbers	true
collapse	true

#
#Example 1: vCPE, Basic Capability and pciePassthroughsriovNICNetwork
#one VNFC(VFC) with one basic capability requirement and two pciePassthroughsriovNICNetwork requirements
#
{
  "service": "hpaPolicy",
  "policyName": "oofCasablanca.hpaPolicy_vFW",
  "description": "HPA policy for vFW",
  "templateVersion": "0.0.1",
  "version": "1.0",
  "priority": "3",
  "riskType": "test",
  "riskLevel": "2",
  "guard": "False",
  "content": {
    "resources": "vG",
    "identity": "hpaPolicy_vG",
    "policyScope": ["vCPE", "US", "INTERNATIONAL", "ip", "vG"],
    "policyType": "hpaPolicy",
    "flavorFeatures": [
      {
        "id" : "<vdu.Name>",
        "type":"vnfc/tocsa.nodes.nfv.Vdu.Compute",
        "directives":[  
           {  
             "directive_name":"flavor_directive",
             "attributes":[  
                {  
                  "attribute_name":"<Blank, or use Default value String 'flavor_name'>",  
                  "attribute_value": "<Blank>" 
                } 
               ]
           }
          ],
        "flavorProperties": [
          {
            "hpa-feature": "basicCapabilities",
            "mandatory": "True",
            "architecture": "generic",
            "directives": [],
            "hpa-feature-attributes": [
              { "hpa-attribute-key": "numVirtualCpu", "hpa-attribute-value": "6", "operator": "=", "unit": "" }
            ]
          },
          {
            "hpa-feature": "basicCapabilities",
            "mandatory": "True",
            "architecture": "generic",
            "hpa-feature-attributesdirectives": [
  ],
           { "hpa-attributefeature-keyattributes": [
              { "hpa-attribute-key": "virtualMemSize", "hpa-attribute-value": "6", "operator": "=", "unit": "GB" },
            ]
          },
          {
            "hpa-feature": "pciePassthroughsriovNICNetwork",
            "mandatory": "True",
            "architecture": "generic",
            "directives" : [
              {
                "directive_name": "pciePassthroughsriovNICNetwork_directive",
                "attributes": [
                   { "attribute_name": "<Blank>",
                     "attribute_value": "<Blank>"
                   },
                   { "attribute_name": "<Blank>",
                     "attribute_value": "<Blank>"
                   }
                ]
              }
            ],
            "hpa-feature-attributes": [
              { "hpa-attribute-key": "pciVendorId", "hpa-attribute-value": "1234", "operator": "=", "unit": "" },
              { "hpa-attribute-key": "pciDeviceId", "hpa-attribute-value": "5678", "operator": "=", "unit": "" },
              { "hpa-attribute-key": "pciCount", "hpa-attribute-value": "1", "operator": ">=", "unit": "" }
            ]
          },
          {
            "hpa-feature": "pciePassthroughsriovNICNetwork",
            "mandatory": "True",
            "architecture": "generic",
            "directives" : [
              {
                "directive_name": "pciePassthroughsriovNICNetwork_directive",
                "attributes": [
                   { "attribute_name": "<Blank>",
                     "attribute_value": "<Blank>"
                   }
                   { "attribute_name": "<Blank>",
                     "attribute_value": "<Blank>"
                   }
                ]
              }
            ],
            "hpa-feature-attributes": [
              { "hpa-attribute-key": "pciVendorId", "hpa-attribute-value": "3333", "operator": "=", "unit": "" },
              { "hpa-attribute-key": "pciDeviceId", "hpa-attribute-value": "7777", "operator": "=", "unit": "" },
              { "hpa-attribute-key": "pciCount", "hpa-attribute-value": "1", "operator": ">=", "unit": "" }
            ]
          }
        ]
      }
    ]
  }
}

...

The data in AAI still follows the routine schema designed in HPA Policies and Mappings. The only part has been changed is inside pciePassthroughsriovNICNetwork. We added one 'directive' attributes to contain the 'vnic_type' and 'physicalNetwork' that needed by VF-C.

...

Code Block

language	js
title	Data inside AAI
linenumbers	true
collapse	true

hpa-capability-id="b369fd3d-0b15-44e1-81b2-6210efc6dff9",
hpa-feature= "basicCapabilities",
architecture= "generic",
version= "v1",
hpa-attribute-key       hpa-attribute-value
numVirtualCpu           {value:6}
virtualMemSize          {value:6, unit:"GB"}


hpa-capability-id="f453fd3d-0b15-11w4-81b2-6210efc6dff9",
hpa-feature= "pciePassthroughsriovNICNetwork",
architecture= "intel64",
version= "v1",
hpa-attribute-key       hpa-attribute-value
pciCount                {value: 1}
pciVendorId             {value: "8086"}
pciDeviceId             {value: "0443"}
directive


hpa-capability-id="f453fd3d-0b15-11w4-81b2-873hf8oo98s0",
hpa-feature= "sriovNICNetwork",
architecture= "intel64",
version= "v1",
hpa-attribute-key       {value: "[{"attribute_name"="vnic_type", "attribute_value"="direct"},hpa-attribute-value
pciCount                {value: 1}
pciVendorId             {value: "6808"}
pciDeviceId        {"attribute_name"="physical_network", "attribute_value"="physnet1"}]"}   hpa-capability-id="f453fd3d-0b15-11w4-81b2-873hf8oo98s0",
hpa-feature= "pciePassthrough",
architecture= "intel64",
version= "v1",
hpa-attribute-key       hpa-attribute-value
pciCount                {value: 1}
pciVendorId             {value: "6808"}
pciDeviceId   {value: "3440"}

OOF process homing allocation and return homing placement to VF-C

OOF will match the requirements inside the policies with the data of the available candidates(cloud-regions or existing candiates) to find an optimal solution to place that service.

After OOF gives out the most appropriate placement for that VNF/services, it will respond the solution back to VF-C with schema like below. Then a module in NSLCM will get that response and store them inside its Database for later instantiation.

Code Block

language	js
title	Sample OOF-VFC response
linenumbers	true
collapse	true

{
  "requestId": "xxxx",
  "transactionId": " xxxx ",
  "statusMessage": " xxxx ",
  "requestStatus": "completed",
  "solutions": {
    "placementSolutions": [
      [
        { "resourceModuleName": " vG ",
          {value"serviceResourceId": "3440"}
directive xxxx ",
          "solution": {
          {value: "[{"attribute_name"="vnic_type", "attribute_value"="direct"},identifierType": "serviceInstanceId",
           "identifiers": [
             " xxxx "
             ],
      {"attribute_name"="physical_network", "attribute_value"="physnet2"}]"}

...

OOF will match the requirements inside the policies with the data of the available candidates(cloud-regions or existing candiates) to find an optimal solution to place that service.

After OOF gives out the most appropriate placement for that VNF/services, it will respond the solution back to VF-C with schema like below. Then a module in NSLCM will get that response and store them inside its Database for later instantiation.

Code Block

language	js
title	Sample OOF-VFC response
linenumbers	true
collapse	true

{
  "requestId": "xxxx",
  "transactionId": " xxxx ",
  "statusMessage": " xxxx ",
  "requestStatus": "completed",
  "solutions": {
    "placementSolutions": [     "cloudOwner": " xxxx "
          },
         "assignmentInfo": [
            {  "key":"isRehome",
               "value":"false"    },
            {  "key":"locationId",
               "value":"DLLSTX1A"    },
            {  "key":"locationType",
       [         { "resourceModuleNamevalue": " vG ","openstack-cloud" },
            {  "serviceResourceIdkey": " xxxx vimId",
       
  "solution": {            "identifierTypevalue": "serviceInstanceId"rackspace_DLLSTX1A"  },
            {  "identifierskey":"physicalLocationId",
[               "value":"DLLSTX1223"  xxxx " },          
  ],          {  "cloudOwnerkey": " xxxx "
 oofDirectives",
        },       "value": {  "assignmentInfodirectives": [
            {    { "keyid":"isRehome<vdu.name>",  
                  "valuetype":"falsevnfc",
   },             {  "keydirectives":"locationId",[                      "value":"DLLSTX1A"    },       
     {  "key":"locationType",              {  "valuetype":"openstack-cloud" },flavor_directive",
                      {  "keyattributes":"vimId",
 [
             "value":"rackspace_DLLSTX1A"  },             {   "keyattribute_name":"physicalLocationIdflavor_name", //just a string 'flavor_name'
           "value":"DLLSTX1223"    },                       {  "keyattribute_value":"oofDirectives<flavor_name>",  #VIM Flavor, which oof  seleted.
        "value": { "directives":[                 { "id":"<vdu.name>", }
                    "type":"vnfc",    ]
              "directives":[       },
                     {    
                     {  "type":"flavor"type": "sriovNICNetwork_directive",
                        "attributes":[
                            {   "attribute_name":"flavorvnic_nametype", //just a string 'flavor_name'"attribute_value":"direct"},
                                {"attribute_name":"provider_network", "attribute_value":"<flavor_name>physnet1"}  #VIM Flavor, which
oof seleted.                       ]
     }                },
        ]                      },
                     {  "{  "type": "pciePassthroughsriovNICNetwork_directive",
                        "attributes": [
                            {"attribute_name":"vnic_type", "attribute_value":"direct"},                
                            {"attribute_name":"provider_network", "attribute_value":"physnet1physnet2"}
                        ]      
]                      },               
         {  "type": "pciePassthrough_directive",        ]                 "attributes": [                      
      {"attribute_name":"vnic_type", "attribute_value":"direct"},           }
                ]
                {"attribute_name":"provider_network", "attribute_value":"physnet2"}}
              }
           ]
         } 
      ]
    ],
    "licenseSoutions": }[
      {
       "resourceModuleName": "string",
       "serviceResourceId": "string",
       "entitlementPoolUUID": [
 ]        "string"
        ],
       "licenseKeyGroupUUID": [
         "string"
        ],
       "entitlementPoolInvariantUUID": [
    }     "string"
        ],
  ]                }
             }
           ]
         } 
      ]
    ],
    "licenseSoutions"licenseKeyGroupInvariantUUID": [
      {
      
"resourceModuleName": "string",        "serviceResourceId": "string",
       "entitlementPoolUUID": [
         "string"
        ],
       "licenseKeyGroupUUID": [
         "string"
        ],
       "entitlementPoolInvariantUUID": [
         "string"
        ],
       "licenseKeyGroupInvariantUUID": [
         "string"
        ]
      }
    ]
  }
}

MultiCloud

OpenStack Config SRIOV

Openstack configuration:

...

An example of a site having three types of compute nodes. 1st set of compute nodes have two SRIOV NIC cards with vendor/device id as 1234, 5678 and vendor/device id as 2345 &6789. 2nd set of compute nodes have two SRIOV-NIC of same type 4321 & 8765. And the third set of compute nodes don't have any SRIOV-NIC cards. And hence OpenStack administrator at the site creates three flavors to reflect the hardware the site has. As you see in this example, it is expected that alias format is followed. Alias value supposed to be of the form "NIC-sriov-<vendor ID>-<device ID>-<Provider network>

$ openstack flavor create flavor1 --id auto --ram 512 --disk 40 --vcpus 4

$ openstack flavor set flavor1 --property pci_passthrough:alias=sriov-nic-intel-8086-0443-physnet1:1

$ openstack flavor set flavor1 --property pci_passthrough:alias=sriov-nic-intel-6808-3440-physnet2:1

Multi-cloud discovery

When it reads the flavors information from OpenStack site, if the pci_passthrough alias starts with SRIOV-NIV, then it assumes that it is SRIOV NIC type.

Next two integers are meant for vendor id and device id.

If it is present after device id, it is assumed to be provider network.

As part of discovery, it populates the A&AI with two PCIe features for Flavor1.

hpa-feature=”pciePassthrough”,

architecture=”{hw_arch}",

version=”v1”,

...

Hpa-attribute-key

...

Hpa-attribute-value

...

pciVendorId

...

8086

...

pciDeviceId

...

0443

...

pciCount

...

1

...

directive

...

[

{"attribute_name": "vnic-type", "attribute_value": "direct"},

{"attribute_name": "physical-network", "attribute_value": "physnet1"},

]

...

"string"
        ]
      }
    ]
  }
}

MultiCloud

OpenStack Config SRIOV

Openstack configuration:

NIC configuration refer to https://docs.openstack.org/neutron/pike/admin/config-sriov.html
An example of a site having three types of compute nodes. 1st set of compute nodes have two SRIOV NIC cards with vendor/device id as 1234, 5678 and vendor/device id as 2345 &6789. 2nd set of compute nodes have two SRIOV-NIC of same type 4321 & 8765. And the third set of compute nodes don't have any SRIOV-NIC cards. And hence OpenStack administrator at the site creates three flavors to reflect the hardware the site has. As you see in this example, it is expected that alias format is followed. Alias value supposed to be of the form "NIC-sriov-<vendor ID>-<device ID>-<Provider network>
$ openstack flavor create flavor1 --id auto --ram 512 --disk 40 --vcpus 4
$ openstack flavor set flavor1 --property pci_passthrough:alias=sriov-nic-intel-8086-0443-physnet1:1
$ openstack flavor set flavor1 --property pci_passthrough:alias=sriov-nic-intel-6808-3440-physnet2:1

Multi-cloud discovery

When it reads the flavors information from OpenStack site, if the pci_passthrough alias starts with SRIOV-NIV, then it assumes that it is SRIOV NIC type.

Next two integers are meant for vendor id and device id.

If it is present after device id, it is assumed to be provider network.

As part of discovery, it populates the A&AI with two PCIe features for Flavor1.

hpa-feature=”sriovNICNetwork”,

architecture=”{hw_arch}",

...

[

{"attribute_name": "vnic-type", "attribute_value": "direct"},

{"attribute_name": "physical-network", "attribute_value": "physnet2"},

]

Hpa-attribute-key	Hpa-attribute-value
pciVendorId	68088086
pciDeviceId	34400443
pciCount	1	directive

hpa-feature=”sriovNICNetwork”,

architecture=”{hw_arch}",

version=”v1”,

Hpa-attribute-key	Hpa-attribute-value
pciVendorId	6808
pciDeviceId	3440
pciCount	1

Multi-cloud API

Code Block

language	text
title	Multi-cloud network API for VF-C
linenumbers	true
collapse	true

Create Network

Request

    {
        "tenant": "tenant1",
        "networkName": "ommnet",
        "shared": 1,
        "vlanTransparent": 1,
        "networkType": "vlan",
        "segmentationId": 202,
        "physicalNetwork": "ctrl",
        "routerExternal": 0
    }

Response

    {
        "returnCode": 0,
        "vimId": "11111",
        "vimName": "11111",
        "status": "ACTIVE",
        "id": "d32019d3-bc6e-4319-9c1d-6722fc136a22",
        "name": "net1",
        "tenant": "tenant1",
        "networkName": "ommnet",
        "shared": 1,
        "vlanTransparent": 1,
        "networkType": "vlan",
        "segmentationId": 202,
        "physicalNetwork": "physnet1",
        "routerExternal": 0
    }

...

Versions Compared

Old Version 17

New Version Current

Key

HPA VF-C External API Interaction for Casablanca

SDC

OOF retrieve the requirements(policies) for that service/VNF inside Policy

OOF process homing allocation and return homing placement to VF-C

MultiCloud

OpenStack Config SRIOV

Multi-cloud discovery

MultiCloud

OpenStack Config SRIOV

Multi-cloud discovery

Multi-cloud API

Page Comparison

Versions Compared

Old Version 17

New Version Current

Key

HPA VF-C External API Interaction for Casablanca

SDC

OOF retrieve the requirements(policies) for that service/VNF inside Policy

OOF process homing allocation and return homing placement to VF-C

MultiCloud

OpenStack Config SRIOV

Multi-cloud discovery

MultiCloud

OpenStack Config SRIOV

Multi-cloud discovery

Multi-cloud API