Page History

...

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

• • • VNFM Adapter Homing Decision for VNF Granting

• • • • Note: the following logic concept is inspired by the VFC Homing decision mechanism.
      • 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

• • • • OOF collects information as following:
        • Service and Resource Info, from: AAI
        • HPA Flavors/Capabilities/Capacity Info, from: AAI
        • Policy Models (Homing, PCI) from: Policy
        • Infrastructure Metrics Info (capacity), from: MultiCloud
        • Cloud Agnostic Intent Info, from: MultiCloud
        • PCI configuration data (not yet a part of SDC model)

• • More SVFM SOL003 Interfaces for Future Release

...

• • SO 
    • SO Catalog DB for SOL001/SOL004 support
    • BPMN Workflows and Recipes
    • VNFM Adapter
  • SDC 
    • Support SOL001/SOL004
    • VF Module deduction based on SOL001
  • SDNC
    • VNF-level Network Assignment, instead of VF-Module
  • A&AI
    • VNF-level Inventory Update
    • VNFM location
  • Policy (Stretch goal) - not for Dublin
    • Scale-Out support for ETSI-based scaling
  • Modeling
    • Support SOL001/SOL004
    • ETSI vs. ONAP-compliant VNFD

• Open Items

• • VNF Application Configuration thru VNFM Adapter and VNFM is under discussion 

    • Architecture subcommittee is defining orchestration scenarios for application configuration

  • Better mechanism for VNFM Adaptor to locate VNFMs (two methods are suggested)

    • How do we identify which VNFM to use?

  • Modelling for VNF and VF Modules; mapping between VF Modules and VNF

    • Assigning Network resources to SDNC; do we use preload data?

    VNFM Adaptor support of VNFD package management (uploading and downloading) for VNFM

  • Continue to support existing non-ETSI SO workflows along with ETSI-based workflows

  • VNFM Adaptor architectural direction; should it work as a thin layer or should it be evolved as a full-fledge NFVO in the future, e.g., handling grant by itself, updating resources in A&AI and SDNC?

    • After the VNF Instantiation, which component does update VNF resources in A&AI? VNFM Adapter or SO?

  • SOL001/SOL004 SO Representation

    • Enhance SO Catalog Database? 

      • VNF_Package (vnfdid, vnfm_info, version, vnf_provider, product, vendor, etc.)

      • VNF_Package_Artifact (child database for VNF_Package, VNFD_URL, SoftwareImage_URL, Additional Files etc)

    • Store minimum reference in TOSCA_CSAR database table?

  • SOL001 Package management

    • SO VNFM Adapter supports VNF Package (VnfPkgInfo, VNFD, Artifact) for VNFM

  • SDNC Preload VNF Topology

  • MultiCloud use