Page History

...

• VNFM Adapter Sub-components

  
  

  Image Modified

  • 
    
    • SO VNFM Adapter component is a sub component of SO; utilizing docker image and container manged.
    • North Bound Interface (NBI)
      • RESTful APIs that support createVnf, instantiateVnf, queryVnf, grantVnf, TerminateVnf
      • Its APIs are SO specific; i.e., not SOL003-based ones
    • Business Logic layer
      • It is invoked by the NBI and provides business logic for createVnf, instantiateVnf, queryVnf, terminateVnf
      • SDNC and A&AI access to collect assignment and VimConnectionInfo
      • Accesses SdcPackageProvider for getting SOL003 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 SVNFMs.

...

• CSAR Import, Store and Retrieve Sequences 

  • SDC stores the original vendor VNF package along with the transformed ONAP-compliant package.
  • SO uses SDC-transformed CSAR packages and VNFM Adapter uses the original Vendor CSAR package.

Image Modified

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

...

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

Image Modified

• 
  
  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 and VF-Module Network to SDNC
     2. Retrieve the VNF and VF-Module 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.

...

• • • • • • If the connection point ip_address_assignment is set to true, set extVirtualLink ip address assignment with configuration data from the user input or a preload file.
            • UI solution (build an UI configuration page and invoke it from VID; it would be an option for the post Dublin release): Impact on VID (open issue)
              • Parse VNFD and extract a list of external virtual links
              • Map the external virtual links to the corresponding connection points, and read ip_address_assignment and number_of_ip_address value
              • Render the external virtual links
              • For each external virtual link, render the ip_address_assignment entry fields based on the number_of_ip_address value
              • User configures the mapping and the UI stores the mapping in the database
              • VNFM Adapter retrieves the mapping from database and fill up the extVirtualLink parameters based the mapping
              • UI Example:

Image Modified

• • • • • • • Preload configuration solution (it would be an option for the Dublin release)
              • For the VNFD, pre-configure the mapping between the external virtual links and the ip addresses
              • VNFM Adapter retrieves the mapping from preload data and fill up the extVirtualLink parameters based on the mapping

...

1. 1. 1. 1. 1. 1. VNFM sends a POST request to the Grant resource with a “GrantRequest” in the body
               2. VNFM Adapter with SO returns to VNFM a “202 Accepted” response with an empty body, and a “Location” header indicates a callback URL
               3. VNFM Adapter with SO makes the granting decision
               4. VNFM keeps trying to obtain the grant by sending a GET request to VNFM Adapter until a “200 OK” response with a “grant” data in the body
               5. VNFM Adapter finishes the granting process and returns a “200 OK” response with a “Grant” data in the body

Image Modified

• • • • VNFM Adapter Homing Decision for VNF Granting

• • • • • Note: the following logic concept is inspired by the VFC Homing decision mechanism (location, inventory data, resource availability, business rules, etc.)
        • Use of OOF is optional. For those models without using HPA, VNFM Adapter will make a grant decision based on VIM registration information. 

Image Modified

1. 1. 
      
      1. 1. VNFM Adapter sends out homing requests to OOF (OSDF) containing resource info
         2. OOF (OSDF) pulls all the related homing constraints from Policy
         3. OOF (HAS) checks AAI database to pull region (flavor) information
         4. OOF (HAS) communicates with Multi-Cloud to check cloud capacity (vims which fulfill the requirements)
         5. OOF (OSDF) returns homing allocation solution to VNFM Adapter

...