Versions Compared

Key

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

Summary: Edge Scoping 

Cloud Infrastructure for Distributed Clouds: ONAP R3+ Cloud Infrastructure ModelingCloud Infrastructure Aggregate Representation Classes 


ONAP ComponentLife Cycle PhaseEnhancements
PolicyDesign

Define Distributed Cloud Infrastructure Placement Policies (Note 3)

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

Support Distributed Cloud Infrastructure Capability Discovery (Note 1, Note 2)

For workload instantiation, translate cloud-agnostic Opaque TLVs from SO into cloud-specific placement attributes (Note 7)

A&AIDeploy

Implement Support Standardized Distributed Cloud Infrastructure Object Hierarchy & Capability Database

  • Loose coupling between HW objects (private cloud) and SW objects (private and public clouds)
  • Includes Standardized Capabilities across clouds & Capabilities unique to certain clouds
  • Note:
      The
        • Multi-Cloud Distributed Cloud Infrastructure Capability Discovery process will populate the aforementioned database
    OOFDeployExecute Distributed Cloud Infrastructure Placement Policies for Optimized Service/VNF Placement across Cloud Regions (Note 4)
    SODeployExtend SO↔OOF API to support opaque TLVs (Note 5)

    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.

    ...

    • For the 5G Service/VNF placement example in Note 3
      • 5G CU-UP VNF maps to a specific Cloud region & Physical DC End Point
      • 5G CU-UP VNF maps to one or more Cloud region(s) 

    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 TLV

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

    Note 7:

    • For the 5G Service/VNF placement example in Note 3
      • Multi-Cloud interprets opaque TLV as Physical DC Endpoint as 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

    End-to-end use case: Definition, Creation & Management of Network Slice

    Edge Automation Requirement:

    Support three types of slices in the Cloud Infrastructure (Definition Reference: https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/)

    ...