Page History

...

• • New SO sub-component, following ONAP Microservice Architecture

  • Generic VNFM Adapter, supporting SOL003-compliant SVNFMs

  • Support SOL003 APIs for VNFM LCM
    • VNF Package management (Download & Parse VNF Package)
      • Get package files from the SDC repository thru SO
      • SO Catalog DB enhancement for SOL001/SOL004 is under discussion, for future release
    • Invoking SVNFM based on SOL003 VNF LCM APIs as a client

      • use https://forge.etsi.org/gitlab/nfv/SOL002-SOL003/2.5.1/master/src/SOL003/VNFLifecycleManagement swagger to create generate a client

      • support Create, Instantiate, Query operations

      • collect data for SOL003 API parameters from SDNC, A&AI and OOF

    • Granting, based on ETSI VNFLifecycleOperationGranting

      • use https://forge.etsi.org/gitlab/nfv/SOL002-SOL003/tree/master/src/SOL003/VNFLifecycleOperationGranting swagger to create generate grant services

      • Grant decisions based on the data from OOF or VIM registration

    • Subscription to SVNFM for getting notifications
      • STARTING, PROCESSING, COMPLETED
  • SVNFM selection based on configuration values that are configured during VNF on-boarding and VNFM registration. Two methods are considered:
    • Correlation between VNF NF Type and VNFM Type (Nokia method)
    • Utilizing VNFD vnfm_info:type, VNFM registration values: VNFM type, Cloud region, vendor

...

• • 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.
  • 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. 
  • 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 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.

Image AddedImage Removed

• Design Scope for Dublin

...

• • Use Cases
  • SOL001/SOL004 Support
  • SOL003 API Support
  • SO VNFM Adapter SOL003 API Support Design
  • VNFM Adapter VNF Package Management
  • SO BPMN Infra & VNFM Adapter RuntimeRun-time Scenario
  • SDNC Assignment Management
  • VNFM Adapter Locating SVNFM
  • VNF Life-cycle Granting
  • VNFM Adapter Homing Decision for VNF Granting
  • VNF and VF-Module Deduction

...

Note: SO future release could consider SOL001/SOL004 internal representation in its Catalog DB, or using the Run-time Catalog DB

• Design

• • TBD

• VNFM Adapter Run-time Scenarios

• • The following diagram depicts BPMN Infra and VNFM Adapter Run-time scenarios.

Image Added

• 1. SO BPMN Service workflows dispatch new resource-level workflows based on VNF request parameters (e.g., type, others).
  2. SO BPMN VNF-level resource workflows handle:
     1. Assign VNF Network to SDNC
     2. Retrieve the Network Assignment from SDNC
     3. Invoke VNFM Adapter Client with required parameters
  3. VNFM Adapter Client manages:
     1. Populate parameter structures based on data from SO workflows
     2. Invoke VNFM Adapter NBI with required parameters
  4. VNFM Adapter gets GenericVNF from A&AI
  5. VNFM Adapter locates the corresponding VNF and VNFM registration info form A&AI (ESR). Two methods are suggested
     1. Current one: based on VNF NF Type and VNFM Type in A&AI
     2. Could use VNFD vnfm_info:type, VNFM registration values: VNFM type, Cloud Region, vendor - logic is being designed
  6. VNFM Adapter gets VimConnectionInfo from A&AI
     1. Queries A&AI based on the cloud region and tenant id
     2. Builds the VimConnectionInfo based on the type, service-url, user-name, password, cloud-domain, etc.
  7. VNFM Adapter uses network assignment (e.g., IP Address) from SO (thru SDNC) and builds the extVirtualLinks and other parameters.

• VF-Module Deduction from SOL001

• • y

• SDNC Assignment

• • TBD

• VNFM Adapter VNF Package Management

...