...
- e.g., MEC APIs - Location info, Radio control info etc.
- e.g., Cloud APIs - IaaS/PaaS + Context Awareness (time, places, activity, weather etc.)
Edge Infrastructure
This diverse work load will require somewhat heterogeneous cloud environment, including Graphical Processing Unit, highly programmable network accelerators, etc., in addition to traditional compute, storage, etc.
...
| Option | ONAP Central (Key Impacted Projects & Enhancements) | ONAP Edge (Key Impacted ONAP Projects & Enhancements) | Edge Cloud Functionality | Related Use Cases & Additional Notes | ONAP Central to ONAP Edge Communication | Release |
|---|
| A | A&AI, Multi-Cloud, Policy, APP-C, VF-C, CLAMP, DCAE, OOF etc. OOF Enhancements
- Example: Choosing the Cloud Region for deployment of Network Functions (PNF/VNF) based on various constraints
- Leverage Infrastructure Events/Alerts besides Metrics for aggregate objects (Tenant, Cluster etc.) from Edge Cloud
Multi-Cloud Enhancements - Multi Cloud standardizes "ONSET" and "ABATE" of Infrastructure Alerts received from Edge Cloud
| *** None *** | - Analytics (Infra/App)
- Value: Summarize data in the edge and avoid WAN bandwidth deluge
- Generate appropriate events and alarms
- Edge Infra Analytics
- Edge App Analytics
- Close Loop Use Cases which need only ONAP Central intervention
- VNF Scale in/out - Proactive using app/infra predictive analytics
- Enhanced Alarm Correlation
- Closed Loop Use cases which does not need ONAP intervention
- Fault Management
- Cloud provider can automatically recover from VM/Host going unresponsive (e.g. heartbeat mechanism)
- VNF/App vendor can automatically recover from VNF/App going unresponsive (e.g. health check mechanism)
- ONAP requires IaaS/PaaS attributes from Cloud providers for Infrastructure profiles that allow Distributed, Highly-secure, Config/Cloud-diverse, Capacity-constrained and Peformance/Isolation-aware – Key Features
| Related Use Cases: Related Work: Notes: - This assumes Analytics and Fault Management Policies in Clouds and VNFs are independently configured.
- Single pane of glass policy management through ONAP involves managing a multi-vendor distributed policy framework and out of scope for R3.
| *** None ***Edge Cloud Instance ABC ↔ Edge Cloud Instance GW ↔ ONAP Central GW ↔ ONAP Central XYZ | Casablanca |
| B | Same as Option A + ONAP Central Project(s) based on Edge DCAE Apps - OOM Enhancements
- 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
- Cloudify Enhancements (Lusheng TBD)
| - ONAP Edge DCAE Microservices
- Support New microservice based Apps – Centralized SON applications, Optimization (SON Drive Test Minimization etc.), ML methodologies for various apps etc.
| Same as Option A | Related Use Cases: Notes: - Choose applications that are independent and which do not impact closed loop operations
| ONAP Edge XYZ ↔ ONAP Edge API GW ↔ ONAP Central API GW ↔ ONAP Central XYZ
| Casablanca |
| C | Same as Option B + ONAP Central Project(s) based on ONAP Edge Closed Loop CLAMP Enhancements - Deploy/Manage a separate Closed Loop per ONAP Edge
| - ONAP Edge Closed Loop
- Edge Policy
- Static/Dynamic Policy - PDP
- Policy may depend on current deployment state and also might need service context for the service component such as VNFs? So, other ONAP components may be involved at the edge?
- Edge APP-C, VF-C, Multi-Cloud for Controller Function
- ...
| Same as Option B |
| Same as Option B | Casablanca+ |
| D | Same as Option C + ONAP Central Project(s) based on ONAP Edge Service Orchestration | - ONAP Edge Service Orchestration
- SO for service orchestration
- OOF for homing
- A&AI for inventory
- ...
| Same as Option C |
| Same as Option C | Casablanca+ |
API GW Options (one or more options are relevant based on use cases):
- Option 1 (desired):
- HTTPS API GW – HTTPS communication across Gateways
- Session termination of local communication from ONAP instance (DMaaP etc.) and translation to HTTPS session to peer API GW
- Benefit
- Hierarchical and Scalable communication across ONAP Central and ONAP Edge instance and/or Edge Cloud instance microservices (avoid full-mesh communication)
- Option 2:
- Secure IPSEC communication across Gateways, especially for public networks
- No Session termination of local communication from ONAP instances (DMaaP etc.)
- Benefit
- Easy Implementation (full-mesh communication) with High Performance
Need to align table with Edge Infrastructure Profile Summary
...