The instantiation request triggers a number of message exchanges, which allows the call flow to be completed in order to instantiate
a VNF instance. The resources are allocated when the VNF instance is instantiated. It requires the VNF instance identifier,
returned by the create VNF request, encoded into the URL to which the request is posted.
The instantiation request sub-tasks within the flow include:
-
Retrieving the VNF Descriptor template from the NFVO.
-
Requesting permission from the NFVO (bi-directional Grant flow). For more information see, Requesting Grant Permission.
Method type:
POST
VNFM Endpoint:
/vnf_instances/{vnfInstanceId}/instantiate
HTTP Request Header:
Content-Type:application/json
Request Payload (ETSI data structure: InstantiateVnfRequest)
{
"flavourId": "default",
"extManagedVirtualLinks": [
{
"id": "my-network",
"resourceId": "93fb90ae-0ec1-4a6e-8700-bf109a0f4fba",
"virtualLinkDescId": "VLD1"
}
],
"vimConnectionInfo": [
{
"accessInfo": {
"password": "P@55w0rd!",
"username": "admin",
"vim_project": "tenantName"
},
"extra": {
"name": "esc"
},
"id": "default_openstack_vim",
"interfaceInfo": {
"baseUrl": "http://localhost:8080"
},
"vimId": "default_openstack_vim",
"vimType": "OPENSTACK"
}
]
"additionalParams": {
"CPUS": 2,
"MEM_SIZE": "512 MB",
"VIM_FLAVOR": "Automation-Cirros-Flavor",
"BOOTUP_TIME": "1800"
}
}
The flavourId value must be same as a single flavour_id specified in the VNFD.
You can customize the VNF before instantiation by adding variables to the VNFD template. Specify the variables in the additionalParams field of the LCM request. The variables are name-value pairs, where the value can be either string, numeric or boolean. In
the example below, the cpus, and mem_size
additionalParams are defined in the VNFD template using the get_input: <TOSCA method>.
Note |
If there are multiple vm groups within the VNFD in a single ETSI deployment, they must all use the same VIM.
|
When this template is submitted to the VNFM, the variables are merged into the same VNF instance. The additionalParams variables are merged with the VNF variables, and actual values for the variables are provided only during instantiation.
The list of parameters supplied are driven by the contents of the VNFD; the additionalParams specified in the request are
used by the VNFD using the get_input TOSCA method within the VNFD. For example, the cpus, and mem_size variables are merged
with the placeholders within the VNFD:
tosca_definitions_version: tosca_simple_yaml_1_2
imports:
- cisco_nfv_sol001_types.yaml
- etsi_nfv_sol001_vnfd_0_10_0_types.yaml
metadata:
template_name: Example
template_author: Cisco Systems
template_version: '1.0'
topology_template:
inputs:
CPUS:
description: Number of CPUs
type: string
default: "2"
MEM_SIZE:
description: Memory size
type: string
default: "512 MB"
VIM_FLAVOR:
description: VIM Flavor
type: string
default: "Automation-Cirros-Flavour"
BOOTUP_TIME:
description: Time taken to boot the VNF
type: string
default: "1800"
node_templates:
vdu1:
type: cisco.nodes.nfv.Vdu.Compute
properties:
name: vdu1
description: Example
configurable_properties:
additional_vnfc_configurable_properties:
vim_flavor: { get_input: VIM_FLAVOR }
bootup_time: { get_input: BOOTUP_TIME }
vdu_profile:
min_number_of_instances: 1
max_number_of_instances: 1
capabilities:
virtual_compute:
properties:
virtual_cpu:
num_virtual_cpu: { get_input: CPUS }
virtual_memory:
virtual_mem_size: { get_input: MEM_SIZE }
If further LCM requests with additionalParams variables are submitted for the same VNF, then the new variables overwrite the existing variables. The VNFM uses the new
variables for instantiation.
Although internal links are designed to be ephemeral, in some deployment scenarios they can be bound to external links that
outlive the VNF. Consider the following example VNFD fragment:
automation_net:
type: tosca.nodes.nfv.VnfVirtualLink
properties:
connectivity_type:
layer_protocols: [ ipv4 ]
description: Internal Network VL
vl_profile:
max_bitrate_requirements:
root: 10000
min_bitrate_requirements:
root: 0
To specify an external virtual link to be used in place of automation_net in the VNF deployment, the following data structure
must be used as part of the instantiation request:
...
"extManagedVirtualLinks": [
{
"id": "net-5ddc8435-9d85-4560-8b95-bfcd3369c5c2",
"resourceId": "esc-net2",
"vimConnectionId":"default_openstack_vim",
"virtualLinkDescId": "automation_net"
}
],
...
Although the ETSI specifications only support the concept of ephemeral volumes, many vendors require the specification of
a persistent volume and so Cisco have implemented an extension to support this. The resource Id of the persistent volume can
be supplied as an additionalParam and tied to a volume in the VNFD using an optional property, as per the following example:
example-volume:
type: cisco.nodes.nfv.Vdu.VirtualBlockStorage
properties:
resource_id: { get_input: EX_VOL_UUID }
virtual_block_storage_data:
size_of_storage: 200 GB
vdu_storage_requirements:
vol_id: 1
bus: ide
type: LUKS
Requesting Permission via Grant
The ETSI API requests for permission from the NFVO to complete lifecycle management operations for the VNF instance resources
and gets resource Ids for any resources pre-provisioned. An example GrantRequest looks like:
{
"flavourId": "default",
"instantiationLevelId": "default",
"isAutomaticInvocation": false,
"operation": "INSTANTIATE",
"vnfInstanceId": "e426a94e-7963-430c-96ee-778dde5bd021",
"vnfLc mOpOccId": "06fe989b-7b0b-40dc-afb3-de26c18651ae",
"vnfdId": "6940B47B-B0D0-48CB-8920-86BC23F91B16",
"addResources":
[
{
"id": "res-1abb1609-a1f3-418a- a7a0-2692a5e53311",
"resourceTemplateId": "vdu1",
"type": "COMPUTE",
"vduId": "vdu1"
},
{
"id": "res-c5ece35c-89e3-4d29-b594-ee9f6591f061",
"resourceTemplateI d": "node_1_nic0",
"type": "LINKPORT",
"vduId": "vdu1"
},
{
"id": "res-e88d8461-5f5a-4dba-af14-def82ce894e5",
"resourceTemplateId": "automation_net",
"type": "VL"
}
],
"_links":
{
"vnfInstance":
{
"href": "https://172.16 .255.8:8251/vnflcm/v1/vnf_instances/14924fca-fb10-45da-bcf5-59c581d675d8"
},
"vnfLcmOpOcc":
{
"href": "https://172.16.255.8:8251/vnflcm/v1/vnf_lcm_op_occs/457736f0-c877-4e07-8055-39dd406c616b"
}
}
}
The corresponding grant returned may look like the following:
{
"id": "grant-0b7d3420-e6ee-4037-b116-18808dea4e2a",
"vnfInstanceId": "14924fca-fb10-45da-bcf5-59c581d675d8",
"vnfLcmOpOccId": "457736f0-c877-4e07-8055-39dd406c616b",
"addResources": [
{
"resourceDefinitionId": "res-1abb1609-a1f3-418a-a7a0-2692a5e53311",
"vimConnectionId": "esc-005e4412-e056-43a9-8bc0-d6699c968a3c"
},
{
"resourceDefinitionId": "res-c5ece35c-89e3-4d29-b594-ee9f6591f061",
"vimConnectionId": "esc-005e4412-e056-43a9-8bc0-d6699c968a3c"
},
{
"resourceDefinitionId": "res-e88d8461-5f5a-4dba-af14-def82ce894e5",
"vimConnectionId": "esc-005e4412-e056-43a9-8bc0-d6699c968a3c"
}
],
"vimAssets": {
"computeResourceFlavours": [
{
"vimConnectionId": "esc-005e4412-e056-43a9-8bc0-d6699c968a3c",
"vimFlavourId": "Automation-Cirros-Flavor",
"vnfdVirtualComputeDescId": "vdu1"
}
],
"softwareImages": [
{
"vimConnectionId": "esc-005e4412-e056-43a9-8bc0-d6699c968a3c",
"vimSoftwareImageId": "Automation-Cirros-DHCP-2-IF",
"vnfdSoftwareImageId": "vdu1"
}
]
},
"vimConnections": [
{
"id": "esc-005e4412-e056-43a9-8bc0-d6699c968a3c",
"vimId": "default_openstack_vim",
"vimType": "OPENSTACK",
"accessInfo": {
"vim_project": "admin"
}
}
],
"zones": [
{
"id": "zone-c9f79460-7a23-43e4-bb6d-0683e2cdb3d4",
"vimConnectionId": "default_openstack_vim",
"zoneId": "default"
},
{
"id": "zone-4039855e-a2cb-48f8-996d-b328cdf9889a",
"vimConnectionId": "default_openstack_vim",
"zoneId": "nova"
}
],
"_links": {
"self": {
"href": "http://localhost:8280/grant/v1/grants/grant-0b7d3420-e6ee-4037-b116-18808dea4e2a"
},
"vnfInstance": {
"href": "https://172.16 .255.8:8251/vnflcm/v1/vnf_instances/14924fca-fb10-45da-bcf5-59c581d675d8"
},
"vnfLcmOpOcc": {
"href": "https://172.16.255.8:8251/vnflcm/v1/vnf_lcm_op_occs/457736f0-c877-4e07-8055-39dd406c616b"
}
}
}
The grant request is accepted only if all the requested resources have been granted, else the grant is rejected.
Retrieving the Deployment Descriptor from ESC
The NFVO can retrieve the ESC datamodel instance in the form of a deployment descriptor. The NFVO can view all the inputs
provided at the time of instantiation and changes made later to the deployment descriptor.
To retrieve the deployment descriptor, you must:
Method Type
GET
VNFM Endpoint
/vnflcm/v1/ext/vnfinstances/{vnfInstanceId}/deployment
HTTP Request Header
content-Type:application/xml
Request Payload
not applicable.
Feedback