I'd like opinions and answers on the following items:
- Has the idea of abstracting NF out of VNF and PNF been considered in the TOSCA node types proposed for ETSI NFV? I think this is of interest to the PNF team and the VES team. See the tosca.nodes.nfv.NF code block and then following discussion for questions.
- I know that use of TOSCA semantics was avoided in the SOL001 spec to not require a consumer of the SOL001 spec to need to use TOSCA orchestration. That means to me that SOL001 is a logical data model (LDM) that just happens to use TOSCA vs. an implementation-specific data model. ONAP is an implementation therefore it should be possible for different components to prune and refactor the model to something most useful. If a component or set of components wants to use TOSCA semantics for orchestration those component(s) are thus free to change the model. It means we could change the TOSCA proposed in SOL001 into TOSCA that DOES leverage TOSCA semantics.
# There is no need to derive VNF or PNF node types at the *data model* level
# Use composition to cover the differences
tosca.nodes.nfv.NF:
derived_from: tosca.nodes.Root
properties:
descriptor_id:
type: string # GUID
required: true
descriptor_version:
type: string
required: true
provider:
type: string
required: true
product_name:
type: string
required: true
software_version:
type: string
required: true
product_info_name:
type: string
required: false
product_info_description:
type: string
required: false
localization_languages:
type: list
entry_schema:
type: string
required: false
default_localization_language:
type: string
required: false
# configurable_properties:
# type: tosca.datatypes.nfv.VnfConfigurableProperties <== remove Vnf prefix?
# required: true
# modifiable_attributes:
# type: tosca.datatypes.nfv.VnfInfoModifiableAttributes <== remove Vnf prefix?
# required: true
# lcm_operations_configuration: # what use is made of this and by whom?
# type: tosca.datatypes.nfv.NfLcmOperationsConfiguration
# description: Describes the configuration parameters for the NF LCM operations
# required: true
# monitoring_parameters:
# type: list
# entry_schema:
# type: tosca.datatypes.nfv.NfMonitoringParameter
# description: Describes monitoring parameters applicable to the NF.
# required: false
flavour_id:
type: string
required: true
# flavour_description: # should be in the NF's DF definition and not need to be provided here (join it with the id)
# type: string
# required: false
# vnfm_info: # I wouldn't recommend putting this in any static model. Maybe a reference to a dynamic property?
# type: list
# entry_schema:
# type: string
# required: true
#capabilities:
# monitoring_parameter:
# modelled as ad hoc capabilities in the VNF node template
requirements:
- virtual_link:
capability: tosca.capabilities.nfv.VirtualLinkable
relationship: tosca.relationships.nfv.VirtualLinksTo
node: tosca.nodes.nfv.VirtualLink # Change to remove vnf
occurrences: [ 0, UNBOUNDED ]
# Work with OASIS on normative representations of compute, storage, architecture, etc.
# I'll just lump them into ExecutionEnvironmentAspects for this example
tosca.capabilities.nfv.Moveable:
derived_from: tosca.capabilities.Root
# Only PNFs could have this capability
tosca.capabilities.nfv.PhysicallyMoveable:
derived_from: tosca.capabilities.nfv.Moveable
# Only VNFs could have this capability
tosca.capabilities.nfv.VirtuallyMoveable:
derived_from: tosca.capabilities.nfv.Moveable
# Only PNFs could have this capability
tosca.capabilities.nfv.PurposeBuiltHostingPlatform:
derived_from: tosca.capabilities.Root
properties:
provider:
type: string
required: true
serial_number:
type: string
required: false
attributes:
serial_number:
type: string
required: true
valid_source_types: []
VendorABC.capabilities.CanHostVendorABCRouter:
derived_from: tosca.capabilities.nfv.PurposeBuiltHostingPlatform
valid_source_types: [VendorABC.nodes.MyPhysicalRouter]
VendorABC.nodes.MyPhysicalRouter: # similar to BaseStation
derived_from: tosca.nodes.nfv.NF
properties:
# omitted for brevity
capabilities:
forwarding: # similar to over the air RF service
type: onap.capabilities.PacketForwarding
requirements:
- host: AssociatedHardware
# This IS the physical aspect of the device, my NF can't work without this
AssociatedHardware: # similar to the airscale box the base station runs on
derived_from: tosca.nodes.Root
properties:
geographic_location_id:
type: string
capabilities:
moveable:
type: tosca.capabilities.nfv.PhysicallyMoveable
host:
type: tosca.capabilities.ExecutionEnvironmentAspects
specificHardware:
type: VendorABC.capabilities.CanHostVendorABCRouter
properties:
serial_number: someValue
VendorXYZ.nodes.MyVirtualRouter:
derived_from: tosca.nodes.nfv.NF
description: this node will be the type of a substitution mapping for a topology template containing the VNFCs for this VNF and their dependencies on their execution environments
properties:
# omitted for brevity
capabilities:
forwarding: # similar to over the air RF service
type: onap.capabilities.PacketForwarding
node_types:
router:
derived_from: tosca.nodes.nfv.NF
capabilities:
onap.capabilities.PacketForwarding
topology_template:
node_templates:
# can match the PNF or the VNF
chooseRouterAtRuntime:
type: router
pnfRouter:
type: VendorABC.nodes.MyPhysicalRouter
vnfRouter:
type: VendorXYZ.nodes.MyVirtualRouter
I need to understand what all the subtyping and indirection is doing in the "modifiable properties example" code block. There is a data type defined which extends VnfInfoModifiableAttributes. It defines its own derived datatype for the extensions property that introduces the http_proxy and https_proxy properties. If I had simply put http_proxy and https_proxy as properties on my derived VNF, I would have had equal access to them in the script; I would have referenced them in a shorter way (i.e., \[vnf, http_proxy\]). I am missing the beauty of all the indirection. Can someone help?
tosca_definitions_version: tosca_simple_yaml_1_2
..
node_types:
mycompany.nodes.nfv.SunshineDB.1_0.1_0:
derived_from: tosca.nodes.nfv.VNF
properties:
..
modifiable_attributes:
type: mycompany.datatypes.nfv.VnfInfoModifiableAttributes
..data_types:
mycompany.datatypes.nfv.VnfInfoModifiableAttributes:
derived_from: tosca.datatypes.nfv.VnfInfoModifiableAttributes
properties:
extensions:
type: mycompany.datatypes.nfv.VnfInfoModifiableAttributesExtensions
required: false mycompany.datatypes.nfv.VnfInfoModifiableAttributesExtensions:
derived_from: tosca.datatypes.nfv.VnfInfoModifiableAttributesExtensions
properties:
http_proxy:
type: string
required: true
https_proxy:
type: string
required: falsetopology_template:
inputs:
modifiable_attributes:
type: mycompany.datatypes.nfv.VnfInfoModifiableAttributes substitution_mappings:
node_type: mycompany.nodes.nfv.SunshineDB.1_0.1_0
.. node_templates:
vnf:
type: mycompany.nodes.nfv.SunshineDB.1_0.1_0
properties:
..
modifiable_attributes: { get_input: modifiable_attributes } dbBackend:
type: tosca.nodes.nfv.Vdu.Compute
properties:
..
boot_data: { concat: [
"#!/bin/bash\n",
"echo setting HTTP proxy to: ", { get_property: [vnf, modifiable_attributes, extensions, http_proxy ] }, "\n",
"..."
] }
..
