Versions Compared

Key

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

...

ONAP ComponentLife Cycle PhaseEnhancements
PolicyDesign

Define Distributed Cloud Infrastructure Service Placement Policies (Note 3) – No enhancement needed to Policy Framework

  • Leverage Standardized Distributed Cloud Infrastructure Object Hierarchy & Capabilities from A&AI
Multi-CloudDeploy

Support Distributed Cloud Infrastructure Capability Discovery (Note 1, Note 2)

IaaS intent-based framework to support cloud agnostic intent for Compute/Network/Storage (

  • Note 7 "Example"
,
  • Note 8 "Execution Workflow"
)

MC <-> Private/Public SDN-DC per Cloud region (Networking Workflow, Ref. 2)

A&AIDeploy

Support Standardized Distributed Cloud Infrastructure Object Hierarchy & Capability Database (Ref. 1)

  • Loose coupling between HW objects (private cloud) and SW objects (private and public clouds)
  • Includes Standardized Capabilities across clouds & Capabilities unique to certain clouds
  • Note:
    • Multi-Cloud Distributed Cloud Infrastructure Capability Discovery process will populate the aforementioned database
OOFDeploy

Execute Distributed Cloud Infrastructure Placement Policies for Optimized Service/VNF Placement across Cloud Regions (Note 4)

OOF ↔ MC Runtime Check API (Note 8 "Execution Workflow")

Resource Reservation Mechanism

SODeploy

Extend SO ↔ OOF API to support cloud agnostic intent (Note 5)

Extend SO ↔ MC API to support cloud agnostic intent (Note 6)

...

  • Cloud Agnostic Intent Execution Workflow
    • 1) OOF → MC runtime check for a specific cloud region which can support capability/capacity/cost metrics (enhance current capacity check API appropriately)
    • 2) MC processes request from OOF
      • Retrieve target Cloud Region specific policy from "Policy"
      • Evaluate each of the cloud specific options in the policy from a perspective of resource allocation, utilization and cost
      • Return to OOF the option which minimizes <resource allocation, utilization and cost> and the net value of the option
        • In case
        there
        • the requirement cannot be met, return appropriate error
      • Cache the option in MC for the specific cloud region as part of the VNF deployment workflow
    • 3) OOF processes request from MC and picks the target cloud region which maximizes the net value
    • 4) SO → MC VNF deployment request is processed by MC
      • MC looks up the cache for the target cloud request with the VNF deployment request details
      • MC replaces appropriate details in the cloud specific template (Heat, ARM etc.) based on the chosen option in the cache
      • MC deploys workload on target cloud region with dynamically modified cloud specific template 
      • MC removes the cache entry for the specific cloud region for the specific VNF deployment 

...