Page History

...

• • The following diagram depicts the component architecture.
  • The VNFM Adapter will be a SO sub-component; packaged as a docker and running in a container.
  • VNFM will register into A&AI ESR and VNFM Adapter will locate a proper VNFM based on VNF NF Type or others.
  • Communications between the VNFM Adapter and SVNFM will be SOL003 API-based.
  • Communications between the SO BPMN Infra VNFM Adapter REST Client and the VNFM Adapter NBI will be SO-specific; i.e., it does not follow ETSI standards at this time.
  • SO SDC Controller receives SOL001/SOL004-based CSAR from SDC, and stores the CSAR reference URLs to TOSCA_CSAR database table. 
    • Currently, VNF package output from SDC is not ETSI alignment. If SDC does not support it Dublin, use the standard package under the artifact directory (e.g., Artifact/Deployment/Others)
    • In Dublin release, there could be two CSAR file contents: one for the original CSAR and one for ONAP-compliant CSAR (maybe the ONAP-compliant CSAR includes the original package)
    • It is assumed that SDC keeps the original vendor VNF packages in their repository, and VNFM Adapter retrieves the original vendor CSAR files from the repository.
  • New VNF-level workflows that use VNFM Adapter will be implemented, and these new workflows will be invoked from the (Network) Service-level workflows based on VNF type and other criteria.
  • Unlike the existing SO VNF/VF-Module workflows, the new VNF-level/VF-Module-level workflows will NOT interact with OpenStack directly. The workflows will delegate the VNF LCM requests to VNFM Adapter, and VNFM Adapter will delegate the requests to VNFM further. Then, VNFM will interact with VIM directly. In Dublin release, the direct mode of resource management will be supported as depicted above.

Gliffy DiagramnameSO VNFM Adapter ArchitecturepagePin11Image Added

• SOL001/SOL004 Standard Conformance

  • VNF Package

    • A VNF Package is a compressed file that contains the following:
      • One VNF descriptor (VNFD)
      • One or more Software Image files
      • Zero or more manifest files
      • Other files

    • Package structure is SOL004 2.5.1 compliant.

  • Cloud Service Archive (CSAR) format

    • It is a packaging construct defined in SOL004 2.5.1, identified by a .csar suffix on the package file. There are two package options. The second option is supported.

    • The CSAR file does not contain TOSCA-Metadata directory, the descriptor yaml file is in the root directory of the CSAR.

    • The CSAR file contains TOSCA-Metadata directory, the TOSCA meta file in this directory contains the location and name of the descriptor file denoted by Entry-Definitions

  • VNFD

    • It is specified by the SOL001 2.5.1.

    • Note that the input and get_input function would be used by a TOSCA orchestrator at run time to access the selected input parameter. If the deployment is not done by a TOSCA orchestrator, the inputs and get_input function may not be needed. The VNFD design should follow the vendor SVNFM orchestration capabilities. 

...