This section provides details about updating ETSI API resource definitions.
Updating the VNF Flavour
A VNF flavour can be updated by updating the TOSCA parameters in the VNFD template. You can define the alternate VNF nodes
and deployment flavours for a single VNFD using the following TOSCA parameters:
-
Import statements—The import statement allows a single, parent VNFD yaml file to conditionally include other files based on an input value
which can be specified dynamically, at run time.
-
Substitution mappings—The substitution mapping applies only to the nodes derived from tosca.nodes.nfv.VNF such as tosca.nodes.nfv.VNF.CiscoESC. You cannot substitute other node types such as Connection Points, networks and so on.
Example1:
In this example, the yaml file contains three import files.
All three files must exist in the VNFD ZIP archive file in the same location as the parent file importing them.
The requirements and capabilities are not defined in the tosca.nodes.nfv.VNF.CiscoESC node. These are mandatory for defining characteristics of VNFs instantiated using this VNFD. They are defined within the
imported files.
tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0
imports:
- subs-mapping-gold.yaml
- subs-mapping-silver.yaml
- subs-mapping-bronze.yaml
description: VNFD Example, single VDU
metadata:
template_name: vnfd-1-VDU-multiflavour
topology_template:
node_templates:
vnf:
type: tosca.nodes.nfv.VNF.CiscoESC
requirements:
#
capabilities:
#
properties:
descriptor_id: 9ee0ce39-cf0a-41ef-b01a-b62b40777901
Example 2:
In this example, with subs-mapping-silver.yaml import file, requirements and capabilities are fully defined under substitution_mappings.
The flavour_id property under capabilities is specified during the invocation of an instantiate or a change VNF flavour operation. The value
of the flavour_id is picked by the matching nodes under substitution_mappings . In the above example, the tosca.nodes.nfv.VNF.CiscoESC node replaces the missing details of the parent yaml.
During instantiation if the input payload contains flavourId: bronze, then the corresponding sections from the subs-mapping-bronze.yaml file are merged into the parent VNFD. If the flavour_id is set to silver, then the sections from the subs-mapping-silver.yaml file is merged and so on.
tosca_definitions_version: tosca_simple_profile_for_nfv_1_0_0
description: Deployment Flavour SILVER
topology_template:
substitution_mappings:
node_type: tosca.nodes.nfv.VNF.CiscoESC
requirements:
virtual_link: [ anECP, external_virtual_link ]
capabilities:
deployment_flavour:
properties:
flavour_id: silver
description: 'SILVER Deployment Flavour'
vdu_profile:
vdu_node_1:
min_number_of_instances: 2
max_number_of_instances: 2
instantiation_levels:
default:
description: 'Default Instantiation Level'
vdu_levels:
vdu_node_1:
number_of_instances: 1
scale_info:
default_scaling_aspect:
scale_level: 2
silver_level:
description: 'SILVER Instantiation Level'
vdu_levels:
vdu_node_1:
number_of_instances: 2
scale_info:
default_scaling_aspect:
scale_level: 2
default_instantiation_level_id: default
vnf_lcm_operations_configuration: {}
scaling_aspect:
- default_scaling_aspect
cisco_esc_properties:
description: "SILVER: This is substituted if not already defined"
ESC sends a POST request to update the VNF flavour:
Method Type:
POST
VNFM Endpoint:
/vnflcm/v1/vnfinstances/{vnfInstanceId}/change_flavour
Updating the External VNF Connectivity
You can update the external VNF connectivity in an existing deployment. The API supports the following changes:
-
Disconnect the existing connection points (CPs) to the existing external virtual link and connect to a different virtual link.
-
Change the connectivity parameters of the existing external CPs, including changing the addresses.
ESC sends a POST request to update the VNF external connectivity:
Method Type
POST
VNFM Endpoint
/vnflcm/v1/vnfinstances/{vnfInstanceId}/change_ext_conn
Request Payload (Data structure = ChangeExtVnfConnectivityRequest)
{
"extVirtualLinks": [
{
"id": "extVL-98345443-7797-4c6d-a0ed-e18771dacf1c",
"resourceId": "node_1_ecp",
"extCps": [
{
"cpdId": "node_1_ecp",
"cpConfig": [
{
"cpProtocolData": [
{
"layerProtocol": "IP_OVER_ETHERNET",
"ipOverEthernet": {
"ipAddresses": [
{
"type": "IPV4",
"numDynamicAddresses": 2,
"subnetId": "esc-subnet"
}
]
}
}
]
}
]
}
]
}
]
}
Note |
The id in the extVirtualLinks, extVL-98345443-7797-4c6d-a0ed-e18771dacf1c in the above example, must also exist in the instantiatedVnfInof in the vnfInstance.
|