Background:
Main purpose is to connect VF-C with OOF and let OOF provide homing placements for VNFs.
This time, we want to put the integration process inside NSLCM.
Detail process like this:
NSLCM trigger GVNFM Driver to create and instantiate VNF inside VNFLCM.
Inside instantiation process, there a part where VNFLCM will apply Grant from NSLCM. During that granting process, NSLCM will call OOF to get homing placement for each VNF.
NSLCM will append the OOF response inside the grant and give back to VNFLCM.
VNFLCM will use the OOF directives to instantiate a VNF.
1. VFC Granting process:
The picture below shows the workflow of granting:
1.VNFLCM call GVNFM Driver through Restful API to invoke the process for granting VNF
2.GVNFM Driver get request from VNFLCM and then sends out a Restful POST to NSLCM.
3.NSLCM received the POST and invoke NFGrant class to give out grant information.
NSLCM call OOF to get homing placement information for each VNF. And attach these information inside the grant response data block and return the response back to GVNFM Driver.
4.GVNFM Driver sends back result to VNFLCM to got through the next steps.
2. VF-C calls OOF for Homing allocation
The table below shows the request parameters required for one OOF request and the value would send from the VF-C.
'serviceResourceId' and 'serviceInstanceId' would be the two parameters that used to map the VNFs.
Request Body | Detailed attributes | Values placed inside | ||
requestInfo | transactionId | UUID generated for Transaction | ||
requestId | UUID generated for Transaction (Can be same as the above one) | |||
callbackUrl | VFC callback URL | |||
requestType | create/update/delete | |||
sourceId | “VFC” | |||
optimizers | “placement” | |||
placementInfo | placementDemands (List) | resourceModuleName | Attribute “vnf_inst_name” in VFC for each VNF | |
serviceResourceId | Attribute “vnfInstanceId” in VFC for each VNF | |||
resourceModelInfo | modelInvariantId | “no-resourceModelInvariantId” | ||
modelVersionId | "no-resourceModelVersionId” | |||
serviceInfo | serviceInstanceId | Attribute “nsInstanceId” in VFC | ||
serviceName | Attribute “ns_inst.name” in VFC | |||
modelInfo | modelInvariantId | A model invariant Id as defined in a service model. | ||
modelVersionId | A unique model Id as defined in a service model. |
3. Grant response to VNFLCM
Add one new data block called 'oof_directives' inside the grant response. The new data block contains all the homing response that get from OOF, including flavor and vnic_info.
Detail structure will look like this:
Attribute Name | Value | ||||||
“vim” | “vimId” | vim_id | |||||
“accessInfo” | “tenant” | tenant info from AAI | |||||
“oof_directives” | “directives” (List) | “vnfc_directives” (List) | “vnfc_id” | vdu_name | |||
“directives” (List) | “directive_name” | {“flavor_directive”, “vnic_info”} | |||||
“attributes” (List) | “attribute_key” | favor_name/ vnic_info | |||||
“attribute_value” | <flavor_name>/ <vnic_type> and <provider_network> | ||||||
“vnf_directives” | “directives” (List) | “directive_name” | / | ||||
“attributes” (List) | “attribute_key” | / | |||||
“attribute_value” | / |
Here is the sample grant response:
rsp = { "vim": {
"vimId": vim_id,
"accessInfo": { "tenant": vim["tenant"] }
“oof_directives”: [
{ “directives”: [
{"vnfc_directives": [
{ "vnfc_id":"",
"directives":[
{ "directive_name": "flavor_directive",
"attributes": [
{"attribute_name": "flavor_label_1", "attribute_value":"HPA.flavor"}
]
},
{ "directive_name": "vnic-info1",
"attributes": [
{"attribute_name": "vnic-type", "attribute_value":"direct"},
{"attribute_name": "provider_network", "attribute_value":"physnet1"}
]
},
{ "directive_name": "vnic-info2",
"attributes": [
{"attribute_name": "vnic-type", "attribute_value":"direct"},
{"attribute_name": "provider_network", "attribute_value":"physnet2"}
]
}
]
}
]
},
{"vnf_directives": [
{ "directives":[
{ "directive_name": “ ",
"attributes": [
{"attribute_name": “ ", "attribute_value":“ "}
]
}
…