Page History

Summary: Edge Scoping 

Distributed Cloud Infrastructure Object Hierarchy, Cloud-agnostic Placement

...

/Networking & Homing Policies

Value:

• 5G VNF Placement & High Performance Networking
• Improve ONAP Deployability through Cloud-Agnostic Intent for Intra-DC Placement & Networking

References: 

• Infrastructure Modelling:
  • ONAP R3+ Cloud Infrastructure Modeling; Cloud Infrastructure Aggregate Representation Classes 
• Intra-DC Networking:
  
  • https://wiki.onap.org/download/attachments/28379482/ONAP-mc-sdn-v2.pptx?api=v2; https://wiki.onap.org/download/attachments/11928197/ONAP-mc-sdn.pdf?version=1&modificationDate=1506518708000&api=v2
    

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 to be fixed to a specific physical DC based on 5G DU, bounded by a max distance from 5G DU

  • Optimization Policy used by OOF

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

Note 4:

• For the 5G Service/VNF placement example in Note 3
  • 5G CU-UP VNF preferably maps to a specific Cloud region & Physical DC End Point 

Note 5:

• For the 5G Service/VNF placement example in Note 3
  • OOF will pass the Physical DC End Point to SO as a 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

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 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
  Cloud Agnostic Intent-based API – Example 1
  • Intent: Rack-level Anti-affinity for VMs within a VNF
  • Different Realization for different clouds
    • OpenStack-based (open source, Wind River, VMware VIO)
      • Heat Template – policy-group, anti-affinity policy
    • Azure
      • Fault-domain
    • AWSPlacement group 
• For the 5G Service/VNF placement example in Note 3
  • 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

Intra-DC networking with Intent-based Cloud Agnostic API (SO → MC → Cloud Region)

References: https://wiki.onap.org/download/attachments/28379482/ONAP-mc-sdn-v2.pptx?api=v2; https://wiki.onap.org/download/attachments/11928197/ONAP-mc-sdn.pdf?version=1&modificationDate=1506518708000&api=v2

Value:

...

5G High Performance Networking 

...

Define Distributed Cloud Infrastructure Network Intent Per Cloud Region (Note 1)

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

...

MC <-> Private/Public SDN-DC – per cloud region interaction

• Translate Cloud Agnostic intent to Cloud specific intent or imperative APIs by querying Policy
• Return network endpoint (used for VNF placement)

...

(SO -> MC -> Private/Public SDN-DC) -- desired

• SO <-> MC IaaS Intent-based intra-dc network instantiation API (Besides Network, also support Compute/Storage as described in the previous section)

• 
  
• Cloud Agnostic Placement Example
  • Intent: Rack-level Anti-affinity for VMs within a VNF
  • Different Realization for different clouds
    • OpenStack-based (open source, Wind River, VMware VIO)
      • Heat Template – policy-group, anti-affinity policy
    • Azure
      • Fault-domain
    • AWS
      • Placement group 
• Cloud Agnostic Networking Example

Note 1:

• Cloud Agnostic Intent Execution
  • 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 or other criteria
    • 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 Intent Execution

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

Cloud Resource Partitioning for Differentiated QoS

Value:

• Applicable to all use cases

• Casablanca Targets:

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

...