Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • ONAP previous analysis
    • The SDC NSD node type, org.openecom.resource.vfc.NSD, is modeled as a component of a VF to represent an allotted resource. But, it is not derived from the org.openecomp.resource.vfc.AllottedResource, either. 
    • The SDC NSD might be designed for Volte use case support, and used by the VFC.
    • It is recommended to deprecate the current SDC NSD node type, and to replace with SOL001 tosca.nodes.nfv.NSD node type.
  • Solutions
    • SDC generates SOL001 tosca.nodes.nfv.NSD node type
    • SDC takes SOL001 NSD with tosca.nodes.nfv.NSD node type as is, without mapping; i.e., no mapping is necessary
    • ONAP SO NFVO uses the SOL001 NSD
    • VFC needs to use the SOL001 NSD

...

  • ONAP previous analysis
    • There is no 1:1 mapping between the SOL001 tosca.nodes.nfv.VNF and org.openecomp.resource.abstract.nodes.VF.
      • SDC VF node types has very few properties.
      • a lot of common properties are added to each node type created by SDC
      • new common properties are mainly about networking and ONAP specific properties
    • There is no clear mapping logic between the current node types
      • SDC creates new data type as ONAP deployment configuration.
  • Solutions
    • map between SOL001 VNF and SDC AID DM VNF selectively.
      • data in the SOL001 that would be considered Cloud Provider automation data could be remained unmapped
      • Examples of Service Provider data that would need to be mapped in order to drive ONAP automation would include:
        • HPA requirements needed by OOF to determine cloud feasibility
        • Input parameters passed to the Cloud provider
      • ONAP wants to distinguish between the mode/data required to drive ONAP functionality from a Service Provider perspective from any ancillary mode/data required to drive Cloud Provider automation.
    • Identify Cloud Provider automation-related data and remove it from the mapping
    • Identify Service Provider data and map it to SDC AID DM
    • ONAP SO NFVO uses SOL001 VNF


SOL001 VNF (tosca.nodes.nfv.VNF)


SDC AID DM VNF (org.openecomp.resource.abstract.nodes.VF)


org.openecomp.resource.vf.vcpeInfrastructureGwDemoApp (derived from org.openecomp.resource.abstract.nodes.VF)
namerequiredtype
namerequiredtype
namerequiredtype
descriptor_idyesstring
nf_function
string
nf_function
string
descriptor_versionyesstring
nf_role
string
nf_role
string
provideryesstring
nf_type
string
nf_type
string
product_nameyesstring
nf_naming_code
string
nf_name_code
string
software_versionyesstring
nf_naming
org.openecomp.datatyhpes.Naming
nf_naming
org.openecomp.datatyhpes.Naming
product_info_nameno string
availability_zone_max_count
integer
availablity_zone_max_count
integer
vnfm_infoyeslist of string
min_instances
integer
min_instances
integer
localization_languagesnolist of string
max_instances
integer
max_instances
integer
default_localization_languageno string
multi_stage_design
boolean
multi_stage_design
boolean
configurable_propertiesnotosca.datatypes.nfv.VnfconfigurableProperties




vf_module_idno
modifiable_attributesnotosca.datatypes.nfv.VnfInfoModifiableAttributes




vcpe_image_nameno
lcm_operations_configuraionnotosca.datatypes.nfv.VnfLcmOperationsConfiguration




public_net_idno
monitoring_parametersnolist of tosca.dataypes.nfv.VnfMonitoringParameter




vgw_name_0no
flavour_idyesstring




nexus_artifact_repono
flavour_descriptionyesstring




mux_ip_addrno
vnf_profilenotosca.datatyhpes.nfv.VnfProfile




vnf_idno








cpe_public_net_cidrno








vg_vgmux_tunnel_vnino








nf_namingno








multi_stage_designno








nf_naming_codeno








vgw_private_ip_0no








vgw_private_ip_1no








vgw_private_ip_2no








pub_keyno








install_script_versionno








onap_private_net_cidrno








cpe_public_net_idno








mux_gw_private_net_idno








dcae_collector_ipno








dcae_collector_portno








onap_private_net_idno








cloud_envno

...