Versions Compared

Key

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

Summary: Edge ScopingArchitecture & Work Items#ONAPEdgeMVP 

...

Table of Contents

...


Distributed Edge Cloud Infrastructure Object Hierarchy (Stretch Goal - Beyond Casablanca)

Value:

  • Fine grained resource management & analytics for Distributed Edge Clouds 

...

  • 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) through intent
      • Cloud Agnostic Intent (Policy) Execution Workflow  - Steps 1- 64

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

  • 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 (no additional implementation dependency), vDNS
  • Types of intent supported (through OOF Policy)
    • "Infrastructure High Availability for VNF" 
    • "Infrastructure Resource Isolation for VNF": "Burstable QoS" "Infrastructure Resource Isolation for VNF": "Guaranteed QoS"for VNF": "Burstable QoS" 
    • "Infrastructure Resource Isolation for VNF": "Guaranteed QoS"
  • Related Specs/Jiras:
  • Useful Links:

Phase 2 (Casablanca Stretch Goal) Summary (Build on Phase 1 Work):

...

(warning) The sequence diagram below expands "Multi-Cloud/VNFM Deploy Apps" in Edge ScopingArchitecture & Work Items Sequence Diagram

Cloud Agnostic Intent (Policy) Workflow Summary (Phase 1 - Casablanca MVP):

Gliffy
size1200
nameCloud Agnostic Intent Execution Workflow
pagePin4142

Cloud Agnostic Intent (Policy) Workflow Details (Phase 1 - Casablanca MVP):

...

Step 4. OOF → SO - Return the target <cloud owner, cloud region> for the Service Instance + deployment-intent per vnfc (code changes in OOF for R3)

OOF

...

...

SO

...

API

...

extension

...

-

...

aligned

...

to

...

the

...

OOF/SO

...

API

...

defined

...

by SO

...

Casablanca

...

HPA

...

Design to

...

minimize

...

the

...

terminology

...

set. The data between OOF to SO and SO to MC is identical -- details of the API are in section 5.

Step 5. SO → MC - Deploy VNF template in the target <cloud owner, cloud region> for the Service Instance (code changes in Multi-Cloud for R3)

...

SO ↔ MC API extension - aligned to the SO/MC API defined by SO Casablanca HPA Design to minimize the terminology set 

...

  • Applicable to all use cases
  • Casablanca Targets:
    • vCPE (Enable Tiered service offering); 5G Network Slicing (Stretch Goal) 

References:

Edge Automation Requirement:

...

View file
namePromethus-aggregation.pdf
height250

ONAP Edge Analytics with DCAE/DMaaP independent of closed loop (Stretch Goal - 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


Multi-Cloud Deployment in Edge Cloud (Stretch Goal - Beyond Casablanca)

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyMULTICLOUD-262

...