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 node types derived from the tosca.nodes.nfv.VNF. You cannot substitute values of other node types that is, Connection Points, Virtual Links 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 derived tosca.nodes.nfv.VNF 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_yaml_1_2
description: Substitution Mapping Example

imports:
- df_default.yaml
- df_silver.yaml
- df_gold.yaml

. . .

node_types:
my-vnf:
derived_from: tosca.nodes.nfv.VNF

. . .

topology_template:

. . .

########################
# Substitution Mapping #
########################
substitution_mappings:
node_type: my-vnf
requirements:
# None

node_templates:

vnf:
type: my-vnf
properties:
descriptor_id: 8717E6CC-3D62-486D-8613-F933DE1FB3A0

. . .

flavour_id: default
flavour_description: Default VNF Deployment Flavour

Example 2:

tosca_definitions_version: tosca_simple_yaml_1_2

description: Silver Deployment Flavour

imports:

topology_template:
substitution_mappings:
node_type: my-vnf
properties:
flavour_id: silver
flavour_description: Silver VNF Deployment Flavour
requirements:
- virtual_link: [ vm1_nic1, virtual_link ]

silver is the flavourId passed in the Instantiate Request payload. The parent yaml shown above has its empty requirements section updated with the requirements from the silver profile, and the existing flavour_id and flavour_description properties are updated as well.

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.

Merging Policy

The substitution merges the new values into the VNFD.

1. For regular scalar properties such as name=joe, the value is replaced in the VNFD.

2. Arrays such as [list, of, strings] are merged. The new values are added into the array, if they do not exist.

3. Objects such as where a key is indented under another key, are replaced. The configurable_properties object in the matched substitution will overwrite that defined in the VNFD.

Parser Behaviour

• If the VNF is instantiated by the Test Harness, the flavour is persisted and used in the subsequent LCM operations so that the VNFD always uses the same mappings.

• If the instantiate operation is called from elsewhere (such as cURL or Postman) then the flavour contained in the grant is persisted and used in the subsequent LCM operations.

• If the Test Harness receives a grant request for a VNF not instantiated through it, then the grant is most likely to fail if no substitution mapping occurs.

• After the substitution mappings are made, the parser tries to populate any additionalParams provided. Note that the command fails if the input parameters do not match those in the template.