Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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:
  1. NSLCM trigger GVNFM Driver to create and instantiate VNF inside VNFLCM.
  2. 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.
  3. NSLCM will append the OOF response inside the grant and give back to VNFLCM.
  4. 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":“ "}

                                              ]

                                          }

                               …

  • No labels