Versions Compared

Key

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

Summary: Edge Scoping 

...

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

...

  • HPA metrics visualization
  • End-to-end use cases: vCPE, vDNS

Casablanca Stretch Goal

  • OOF to use aggregated telemetry information for fine-grained optimization

...

View file
namePromethus-aggregation.pdf
height250

ONAP Edge Analytics with DCAE/DMaaP independent of closed loop (Beyond Casablanca)

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

...