Versions Compared

Old Version 55

changes.mady.by.user ramki krishnan

Saved on

compared with

New Version 56

changes.mady.by.user ramki krishnan

Saved on

Key

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

Summary: Edge Scoping 

Distributed Cloud Infrastructure Object Hierarchy

...

(Stretch Goal?)

Value:

  • Fine grained resource management & analytics for Distributed Edge Clouds
  • VNF Placement & High Performance Networking (5G and beyond)
  • Improve Workload Deployability through Cloud-Agnostic Intent for Intra-DC Placement & Networking

References: 


ONAP

...

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)

...

  • For the 5G Service/VNF placement example in Note 3
    • SO passes the Physical DC End Point to Multi-Cloud as a cloud agnostic intent, besides the Cloud Region

...

Cloud

...

  • HPA attributes (e.g. Smart NIC Family, GPU Family) based on Cloud specific HW/SW support
  • Normalized CPU capacity for VMs/Containers based on Cloud specific HW support
  • Fine-grained Placement attributes based on Cloud specific SW support
    • e.g., Rack-level Anti-affinity-> Azure: Fault-Domain, AWS: Placement-Group 
    • e.g., Exclusivity ->                   Azure: Isolated VM, AWS: Dedicated Host 
    • e.g., Fine grained QoS ->       VMware Minimum guarantee, Kubernetes Burstable Class

...

  • Multi-Cloud interprets cloud agnostic intent as Physical DC Endpoint and translates to cloud-specific placement attribute such as Availability Zone
    • For this example, each distributed physical DC is in a separate Availability Zone for a OpenStack-based Cloud

-agnostic Placement/Networking & Homing Policies (Casablanca MVP)

Value:

  • VNF Placement & High Performance Networking for all use cases
    • Improve Workload Deployability through Cloud-Agnostic Intent for Intra-DC Placement & Networking
    • Support capacity check (besides capability check) for HPA resources 
    • Applicable to all workloads - VM-based or Container-based

References: 

End-to-end use case Alignment:

  • Implement the examples (Smart NIC optional) in the "Cloud Agnostic Intent Execution Workflow" for 5G & vCPE use cases

Note 7: 

...

  • Heat Template – policy-group, anti-affinity policy

...

  • Fault-domain

...

  • Cloud Agnostic Networking Example
    • Intent: High Performance Intra-DC data plane networking
    • Several Realization Options per Cloud – the final realization choice could be based on least current resource usage, cloud capability, cost etc.
      • Overlay in SmartNIC
      • Gateway in SmartNIC
      • Overlay in DPDK-based switch/router
      • Gateway in DPDK-based switch/router
      • Overlay in ToR
      • Gateway in a ToR
      • Gateway in a HW appliance
    • Realizations which are fixed
      • Underlay maps to ToR/Network Fabric
      • No CPU usage for data plane networking maps to VMs/Containers with SR-IOV support
  • Cloud Agnostic Resource Slice Isolation (Tenant) Example

    • Intent: Resource Slice (Tenant) Isolation 

      • Details in next section on "Cloud Resource Partitioning for Differentiated QoS"

    • Several Realization Options per Cloud – the final realization choice could be based on least current resource usage, cloud capability, cost etc.
      • Guaranteed Resource Slice (hard isolation) for various infra Resources (CPU/Memory/Network)
      • Burstable Resource Slice (soft isolation) for various infra Resources

Note 8:

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

(warning) The sequence diagram below expands "Multi-Cloud/VNFM Deploy Apps" in Edge Scoping Sequence Diagram

Gliffy Diagram
nameCloud Agnostic Intent Execution Workflow
pagePin20

Cloud Resource Partitioning for Differentiated QoS (Combined with previous)

Value:

  • Applicable to all use cases

  • Casablanca Targets:

    • vCPE (Enable Tiered service offering); 5G Network Slicing (Stretch Goal) 

...

ONAP ComponentLife Cycle PhaseEnhancements
PolicyDesign

Configuration Policies for Guaranteed, Burstable & Best Effort Cloud Infrastructure Resource Slices (this will apply to VMs/Containers also)

Placement Policies for Resource Slices

  • Higher (programmable) weight to Cloud Region which supports all three types of resource slices vs only two types of resource slices (Guaranteed/Best Effort)
Multi-CloudDeployResource Slice Capability Discovery
A&AIDeploy

Resource Slice Capability per Cloud Region

  • Guaranteed/Burstable/Best Effort

Resource Slice Type

  • Guaranteed/Burstable/Best Effort
OOFDeploy

Execute Resource Slice Placement Policies for Optimized Service/VNF Placement across Cloud Regions

Aggregated Infrastructure Telemetry Streams (Stretch Goal?)

Value

  • Edge Infrastructure Analytics complementing 5G VNF Analytics

...

ONAP ComponentLife cycle phaseActivities
AAI and ESRDeploy & Run time
  • Add/Modify/Delete recording and alerting rules
AAI and ESRRun time
  • Add/Modify/Delete Edge-cloud information
Multi-CloudRun time
  • Get Edge information from A&AI whenever Edge-Cloud is added or removed.
  • Prepare to wait for information from that Edge-cloud
  • Receive information from edge-cloud and put it in the time series DB.
  • Summation based on recording & alerting rules
  • Export information to DCAE via DMAPP or VES

ONAP Edge Analytics with DCAE/DMaaP independent of closed loop (Stretch Goal?)

Value

  • 5G Analytics

ONAP ComponentLife cycle phaseEnhancements
OOM - ONAP CentralDeploy
  • Separate ONAP-edge Instance per 'edge domain', (ie., separate from onap-central instance, of course)
    • Note: Independent of any Edge CP's Orchestration components.
  • SP uses a central-OOM with a 'policy' for deployment of an onap-edge instance, e.g., xyz edge provider with abc components, etc.
    • However, onap-edge instance can be 'lighter weight' with subset of components needed (per MVP discussed below)
    • Desirable to managed as a separate K8s cluster (ie., separate from onap-central instance, of course) and, only for onap-edge use, ie., don't use for other 'workloads' like network apps or 3rd party apps
  • Central OOM to deploy the following ONAP edge instance
    • DMaaP with mirror capability