VNFD example
tosca_definitions_version: tosca_simple_profile_yaml_1_1
description: the VNFD of MyVnf
node_types:
MyCompany.MyVnf.1_0.1_0: # node type of MyVnf
derived_from: tosca.nodes.nfv.VNF
properties:
descriptor_id:
type: string
constraints: [ valid_values: [ b1bb0ce7-ebca-4fa7-95ed-4840d70a1177 ] ]
default: b1bb0ce7-ebca-4fa7-95ed-4840d70a1177
provider:
type: string
constraints: [ valid_values: [ MyCompany ] ]
default: MyCompany
product_name:
type: string
constraints: [ valid_values: [ MyVnf ] ]
default: Myvnf
software_version:
type: string
constraints: [ valid_values: [ '1.0' ] ]
default: '1.0'
descriptor_version:
type: string
constraints: [ valid_values: [ '1.0' ] ]
default: '1.0'
flavour_id:
type: string
constraints: [ valid_values: [ simple ] ] #only one and only allowed one DF in this example
default: simple
flavour_description:
type: string
vnfm_info:
type: list
interfaces:
Nfv:
instantiate:
inputs:
parameter_1:
type: string
required: false
default: value_1
parameter_2:
type: string
required: false
default: value_2
terminate:
implementation: terminate.workbook.mistral.yaml
topology_template:
substitution_mappings:
node_type: MyCompany.MyVnf.1_0.1_0
requirements:
- virtual_link: [ Cp_2, external_virtual_link ] # expose as external CP
- virtual_link: [ Cp_4, external_virtual_link ] # expose as external CP
node_templates:
VDU_compute_1:
type: tosca.nodes.nfv.Vdu.Compute
properties:
name: ..
description: ..
boot_order: ..
nfvi_constraints: ..
configurable_properties:
additional_vnfc_configurable_properties: {}
vdu_profile:
min_number_of_instances: 1
max_number_of_instances: 4
capabilities:
virtual_compute:
properties:
virtual_memory:
virtual_mem_size: 8096 MB
virtual_cpu:
cpu_architecture: x86
num_virtual_cpu: 2
virtual_cpu_clock: 1800 MHz
requirements:
- virtual_storage: Storage_1
Storage_1:
type: tosca.nodes.nfv.Vdu.VirtualStorage
properties:
type_of_storage: ..
size_of_storage: 100MB
rdma_enabled: ..
Cp_1:
type: tosca.nodes.nfv.VduCp
properties:
layer_protocol: ipv4
role: leaf
description: Internal connection point on an VL
requirements:
- virtual_binding: Vdu_1
- virtual_link: internalVl_1
internalVl_1:
type: tosca.nodes.nfv.VirtualLink
properties:
connectivity_type:
layer_protocol: ipv4
flow_pattern: mesh
test_access: []
description: ..
vl_profile:
qos:
maxBitRateRequirements:
minBitRateRequirements:
Cp_2:
type: tosca.nodes.nfv.VduCp
properties:
layer_protocol: ipv4
role: leaf
description: External connection point to access exteranlVl_1
requirements:
- external_virtual_link:
- virtual_binding: Vdu_1
VDU_compute_2:
type: tosca.nodes.nfv.Vdu.Compute
properties:
name: ..
description: ..
boot_order: ..
nfvi_constraints: ..
configurable_properties:
additional_vnfc_configurable_properties: {}
vdu_profile:
min_number_of_instances: 2
max_number_of_instances: 6
capabilities:
virtual_compute:
properties:
virtual_memory:
virtual_mem_size: 8096 MB
virtual_cpu:
cpu_architecture: x86
num_virtual_cpu: 4
virtual_cpu_clock: 1800 MHz
Cp_3:
type: tosca.nodes.nfv.VduCp
properties:
layer_protocol: ipv4
role: leaf
description: Internal connection point on an VL
requirements:
- virtual_binding: Vdu_2
- virtual_link: internalVl_1
Cp_4:
type: tosca.nodes.nfv.VduCpd
properties:
layer_protocol: ipv4
role: leaf
description: External connection point to access exteranlVl_2
requirements:
- external_virtual_link:
- virtual_binding: Vdu_2
4 Comments
yuanxing feng
I note that flavour_id is defined as a mandatory property of VNF node type, and flavor_description is the same thing. It seems to me that it's a little different from R2 IM clean version where we have an attribute of deploymentFlavour as an object.
My concern is where flavor_id comes from and how to deal with this property because till now we don't have any use cases or feature requirements about that.
shitao li
This is based on the latest ETSI NFV SOL001 v0.6.0, where it maps flavour_Id as a property of the VNF node type. Please refer to annex A.1 in SOL001 for more information.
Chesla Wechsler
Let's say I have a basic type hierarchy whereby NetworkFunction is a node type.
I have a NetworkFunction that requires a pre-provisioned PNF Device, then I have a PNF.
If the NetworkFunction requires a provider service, I have an allotted NetworkFunction.
If I have a NetworkFunction that requires neither, it's a VNF.
Let's say I derive Firewall from NetworkFunction.
With that type of node hierarchy, the OASIS non-normative recommendation for abstract node type resolution could be exploited to let a service provider use the Firewall node type in its service template, and let ONAP choose, based on standard TOSCA semantics (including policy) whether to satisfy that Firewall with a VNF, PNF, or Allotted Network Function.
A use case of this could be a uCPE device with a Network Operation System that has embedded network functions available as well as being able to support traditional VNFs. That embedded network function could be modeled as an Allotted Network Function (as provided by the NOS). Depending on the capabilities needed in the firewall, the service might be able to be satisfied with either the embedded NF or the VNF.
This gives a service provider a lot of flexibility to test a number of candidate VNFs that could be used within a service an optimize which get selected, all in a model driven way.
I don't see tosca.nodes.nfv.VNF, which is derived from tosca.nodes.Root, giving the same flexibility. Could it be changed to permit this? For example, could there be a tosca.nodes.nfv.NF which captures properties common to all NetworkFunctions and then exploit the same sort of requirement/capability approach as described above to delineate whether something is a PNF, VNF, or Allotted NF?
Tim Bruton
I tried to graft the above VNDF example into a MainServiceTemplate.yaml file inside a .csar file and onboard it, but the "Attachments" "Setup" page has no ARTIFACTS listed.
I am using SDC R2 code from the gerrit repository and overnight 1.2-STAGING_latest docker images.
Has anyone got an example .csar file that will load?