Versions Compared

Key

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

...


    • 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. 
      • Note: there could be two CSAR filesfile 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.

...


    1. SO SDC Controller gets a SOL004 VNF package with an SOL001 VNFD
      1. SDC could generate two output: one ONAP-compliant CSAR and one original CSAR (maybe the first file includes the second one)
      2. SO will use the ONAP-compliant CSAR
      3. VNFM Adapter will use original CSAR
    2. SO SDC Controller stores a VNF CSAR file reference to the SO Catalog DB (e.g., TOSCA_CSAR database table)
    3. VNFM Adapter gets a CSAR package URL from the SO TOSCA_CSAR database table
    4. VNFM Adapter gets an original CSAR package file from the SDC repository
      1. It is assumed that the Adapter retrieves the original vendor provided CSAR package from SDC repository directory before it passes the package to SVNFM, where SVNFM handles the original CSAR. For that, SDC copy the full original package.
      2. There would be two CSAR packages for a service: one original package, one SDC transformed package.
      3. VNFM Adapter passes the original CSAR package to SVNFM because the SVNFM is outside of ONAP and is designed to handle the vendor CSAR package.

...