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?