Page Comparison

...

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 opaque data

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 data, besides the Cloud Region

Cloud-agnostic Placement/Networking & Homing Policies (Phase 1 - Casablanca MVP, Phase 2 - Stretch Goal)

...

Multi-Cloud Policy Framework
- Assist OOF in target cloud region selection for VNF placement (aka homing) by summarizing cloud-specific capability, capacity & cost metrics (e.g. VMs could have different cost in different clouds, Infra High Availability (HA) for VMs in a VNF could have different cost in different clouds)
  - Cloud Agnostic Intent (Policy) Execution Workflow - Steps 1- 6
- Dynamically modify the cloud specific VNF deployment template based on cloud-specific realization of the specified intent (e.g. Infra HA for VMs within a VNF could have different realizations across different clouds)
  - Cloud Agnostic Intent (Policy) Execution Workflow - Step 7
Intent Support
- Single realization option per Cloud Region for the specified Intent
Impact Projects:
- Multi-Cloud (Highest), OOF, SO (Minimal)
End-to-end use case demonstration:
- vCPE (higher priority – no additional implementation dependency), vDNS

...

View file

name	Promethus-aggregation.pdf
height	250

ONAP Component	Life cycle phase	Enhancements
OOM - ONAP Central	Deploy	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

...