Edge Scoping MVP for Casablanca - ONAP Enhancements

Summary: Edge Scoping 

Cloud Infrastructure for Distributed Clouds: ONAP R3+ Cloud Infrastructure Modeling; Cloud Infrastructure Aggregate Representation Classes 

Assumption for Policy, SO, OOF:

• This uses the current Generic VNF workflow in SO

Note 1: 

• Configured Capacity and Utilized (or Currently Used) Capacity are managed by the specific cloud.

Note 2:

• Cloud SW Capability example 
  • Cloud region "x" with SR-IOV, GPU, Min-guarantee support
  • Cloud region "y" with SR-IOV support
• Cloud HW Capability example 
  • Resource cluster "xa" in Cloud region "x" with SR-IOV and GPU support 
  • Resource cluster "xb" in Cloud region "x" with GPU support
  • Resource cluster "ya" in Cloud region "y" with SR-IOV support

Note 3:

• 5G Service/VNF placement example
  • Constraints used by Optimization Framework (OOF)

    • 5G CU-UP VNF location is fixed to a specific physical DC based based on subscriber group

    • 5G CU-CP VNF to 5G CU-UP VNF Data Center connectivity latency cannot exceed certain value

  • Optimization Policy used by OOF

    • Choose optimized cloud region (or instance) for the placement of 5G CU UP/CP for subscriber group based on the above constraints

Note 4:

• For the 5G Service/VNF placement example in Note 3
  • 5G CU-UP VNF maps to a specific Cloud region & Physical DC End Point
  • 5G CU-UP VNF maps to one or more Cloud region(s) 

Note 5:

• For the 5G Service/VNF placement example in Note 3
  • OOF will pass the Physical DC End Point to SO as a opaque TLV

Note 6:

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

Note 7:

• Cloud agnostic placement attributes are targeted to abstract the following cloud specific placement attributes
  • 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
    
    • Reference for CPU Normalization:  https://d1.awsstatic.com/whitepapers/Demystifying_vCPUs.df200b766578b75009ad8d15c72e493d6408c68a.pdf
  • Fine-grained Placement attributes (e.g. affinity, anti-affinity, specific physical DC) based on Cloud specific SW support
• For the 5G Service/VNF placement example in Note 3
  
  • Multi-Cloud interprets opaque TLV as Physical DC Endpoint as 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

End-to-end use case: Definition, Creation & Management of Network Slice - Cloud Infrastructure Impact 

Edge Automation Requirement:

Support three types of slices in the Cloud Infrastructure (Definition Reference: https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/)

• Guaranteed Resource Slice (hard isolation) for various infra Resources (CPU/Memory/Network)
  • Max (limit), Min (request) are the same; resource guarantee is "Max"
  • Maps to Guaranteed Network Slice for 5G Cloud RAN
• Burstable Resource Slice (soft isolation) for various infra Resources
  • Min (request) <= Max (limit); resource guarantee is "Min"
  • Maps to Burstable Network Slice for 5G Cloud RAN
• Best Effort Resource Slice (no isolation) for various infra Resources
  • No Min (request) ; resource guarantee is "None"
  • Maps to Best Effort Network Slice for 5G Cloud RAN

Assumption:

• This uses the new Network Slicing workflow in SO (todo)