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:
- Intra-DC Networking:
ONAP Component | Life Cycle Phase | Enhancements |
---|---|---|
Policy | Design | Define Distributed Cloud Infrastructure Placement Policies (Note 3) – No enhancement needed to Policy Framework
|
Multi-Cloud | Deploy | Support Distributed Cloud Infrastructure Capability Discovery (Note 1, Note 2) SO ↔ MC IaaS intent-based workload instantiation API to support cloud agnostic intent for Compute/Network/Storage; MC to translate cloud-agnostic intent from SO into cloud-specific placement & networking attributes (Note 7) Networking – MC <-> Private/Public SDN-DC per Cloud region |
A&AI | Deploy | Support Standardized Distributed Cloud Infrastructure Object Hierarchy & Capability Database
|
OOF | Deploy | Execute Distributed Cloud Infrastructure Placement Policies for Optimized Service/VNF Placement across Cloud Regions (Note 4) Resource Reservation |
SO | Deploy | Extend SO ↔ OOF API to support cloud agnostic intent (Note 5) |
TBD (Multi-Cloud or OOF) | Deploy | Placement Service per Cloud Region
|
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
- Constraints used by Optimization Framework (OOF)
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
- 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
- OpenStack-based (open source, Wind River, VMware VIO)
- 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
- Multi-Cloud interprets cloud agnostic intent as Physical DC Endpoint and translates to cloud-specific placement attribute such as Availability Zone
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
- OpenStack-based (open source, Wind River, VMware VIO)
- 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)
...