Page History

...

• • Leverage ETSI standards for VNF LCM in SO

  • Build SO VNFM Adapter

    • Use SOL003 APIs (2.5.1) for VNF LCM

    • Support operations such as create, instantiate, grant, terminate/, delete, LCN subscription and LCN

    • Support of Delete VNF is a stretch goal in Dublin

  • Enhance SO BPMN workflows & recipes

    • VNF-level Building Block workflows, leveraging VNFM Adapter 

    • Passing VNF LCM requests to VNFM using VNFM Adapter

• Note: the followings are candidates for the El Alto release.

  • Provide VNF package management for VNFM

  • Policy-based VNF scaling thru VNFM Adapter

  • Support of remaining SOL003 APIs
  • VNF Package handling (Download & Parse VNF Package)
    • Get package files from the SDC repository thru SO
    • Provide VNF package(s), VNFDs and Artifacts to VNFM
    • SO Catalog DB enhancement for SOL001/SOL004 is identified as future release work

...

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

    • Note: SDC in Dublin has limitations and restrictions on SOL004 support:
      • SDC does not allow custom directories such as Images, Scripts, Licenses and HOT in the root directory.
      • SDC requires MainServiceTemplate.mf and MainServiceTemplate.yaml in the root directory
      • As a result, in Dublin, the vendor VNF package should follow SDC onboarding rules. These SDC restrictions and limitations plan to be removed in the El Alto release. 

  • 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. In SOL004, there are two package options; one with TOSCA-Metadata, one without TOSCA-Metadata directories: 

      • 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

    • In ONAP, the second option (with TOSCA-Metadata) is supported.
    • Note: in SDC El Alto, if the VNF package with certificate and/or signature will be packaged as a zip file. The csar format continues to be used for the package without certificate and/or signature. The zip file without certificate and/or signature will be considered as an HEAT-based package.

  • VNFD

    • It is specified by the SOL001 2.5.1.

    • Note 1: 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. 
    • Note 2: in Dublin, SDC will convert SOL001 VNFD to SDC AID DM, but it is not complete. More mapping design discussions are necessary in El Alto.

...

• • Epic and Use Stories
  • VNFM Adapter Design
  • SOL001/SOL004 Support & Design
  • SO BPMN Infra & VNFM Adapter Run-time Scenario
  • SOL003 API Support
  • SO VNFM Adapter SOL003 API Support Design
  • VNFM Adapter VNF Package Management (Not part of Dublin)
  • SDNC Assignment Management
  • VNFM Adapter Locating SVNFM
  • VNF Life-cycle Granting
  • VNFM Adapter Homing Decision for VNF Granting (TBD)
  • SVNFM Simulator

• Epic

• User Stories

...

• • SO VNFM Adapter component is a sub component of SO; utilizing docker image and container managed.
    • North Bound Interface (NBI)
      • RESTful APIs that support createVnf (invokes both createVnf and instantiateVnf), grantVnf, TerminateVnf/DeleteVnf
      • Its APIs are SO specific; i.e., not SOL003-based ones; for the NB API details, see the SO VNFM Adapter APIs page.
    • Business Logic layer
      • It is invoked by the NBI and provides business logic for createVnf, instantiateVnf, terminateVnf/DeleteVnf
      • SDNC and A&AI access to collect assignment and VimConnectionInfo
      • Accesses SdcPackageProvider for getting SOL004 package(s) and parameters
      • SdcPackageProvider
        • Supports SOL001/SOL004 package management
        • Provides getPackage, getVnfdId, getFlavorId, getVnfNodeProperty
        • Provides getPackage(s), getVnfd, getArtifactFile for SVNFM
        • Uses SDC Tosca Parser
      • GrantManager
        • Provides requestGrantForInstantiate REST API for SVNFM
        • Invokes OOF for homing decision; HPA support, and/or non-OOF decision
      • SOL003Lcn APIs
        • Supports VnfIdentifierCreationNotification, VnfIdentifierDeletionNotification, VnfLcmOperationOccurrenceNotification
    • SOL003 Communication Layer
      • It is a thin REST client layer, which sends SOL003-compliant requests to SVNFMs and receives responses/notifications from SVNFM.
      • For Grant, it provides the Grant REST endpoint for SVNFM
      • For the SOL003 Southbound API details, see the  SO VNFM Adapter APIs page.

...

• 
  
  1. SO BPMN Service workflows dispatch new resource-level workflows based on VNF request parameters (e.g., type, others).
     1. Once a Service workflow chooses a new workflow path for VNFM Adapter, the subsequent requests for the same VNF will follow the new path.
     2. an association between VNF and VNFM will be made in A&AI.
  2. SO BPMN VNF-level resource workflows handle:
     1. Assign VNF to SDNC
     2. Retrieve the VNF 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.

...