You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 3
Next »
Architectural Deployment Scenarios to consider:
Management Workloads
Deployment Model | Edge using certain ONAP management workload functions as an Offload
|
| Description | Architecture Near-term Priority |
Edge and Central Provider are same | - Allows ONAP Central Controller function to install ONAP SW components (purely ONAP mgmt. based or 3rd party integrated with ONAP mgmt.).
- This also supports ONAP specific K8S cluster installation.
| Priority - High? Rationale: - Analytics and closed loop offloads are key edge use cases
Note: Analytics is currently addressed by a Distributed DCAE Orchestrator based on Cloudify. Participant Operator Priority - AT&T - ?
- Reliance Jio - ?
- Verizon - ?
- Vodafone - ?
|
Edge and Central Providers are different | - Use Existing VPCs (VPC creation out of scope for ONAP)
- Rest - Same as above.
| Priority - High? Rationale - Same as above. Participant Operator Priority - AT&T - ?
- Reliance Jio - ?
- Verizon - ?
- Vodafone - ?
|
Managed Workloads
Deploy-ment Model | Edge using certain ONAP management workload functions as an Offload
| Edge *not* using ONAP Orchestration Clarification Notes: This assumes at least a two level hierarchy for orchestration - ONAP Central Orchestrator and 3rd party Edge Orchestrator. This is specific to Service (VNF/App) Orchestration and *not* Cloud infrastructure orchestration. Interfacing to cloud infrastructure is already covered through ONAP multi-cloud. |
| Description | Architecture Near-term Priority for VNFs | Architecture Near-term Priority for Apps | Description | Architecture Near-term Priority for VNF Orchestration | Architecture Near-term Priority for App Orchestration |
Edge and Central Provider are same | - Managed workloads are always instantiated by ONAP components
- In case the ONAP Mgmt. Offload to Edge is Analytics or Closed Loop components
- ONAP Central SO uses ONAP Central Multi-Cloud APIs to instantiate workloads
- In case the ONAP Mgmt. Offload to Edge is Orchestration components
- ONAP Central SO uses ONAP Edge SO APIs to instantiate workloads
| Priority - High? Rationale: - Analytics and closed loop offloads are key edge use cases
Participant Operator Priority - AT&T - ?
- Reliance Jio - ?
- Verizon - ?
- Vodafone - ?
| Priority - Medium? Rationale: - ONAP's primary focus is NFV Orch.
Participant Operator Priority - AT&T - ?
- Reliance Jio - ?
- Verizon - ?
- Vodafone - ?
| - Managed workloads are always instantiated by *non* ONAP components
- ONAP Edge orchestrator should be registered in ONAP central with the service specific capabilities it can offer. This step should happen before service instantiation.
| Priority - Medium? Rationale: - This is more of a standardization exercise given that different NFV orchestrators typically have different APIs
Participant Operator Priority - AT&T - ?
- Reliance Jio - ?
- Verizon - ?
- Vodafone - ?
| Priority - Medium? Rationale: - ONAP's primary focus is NFV Orch.
- This is more of a standardization exercise given that different NFV orchestrators typically have different APIs
Participant Operator Priority - AT&T - ?
- Reliance Jio - ?
- Verizon - ?
- Vodafone - ?
|
Edge and Central Providers are different | - Use Existing VPCs (VPC creation out of scope for ONAP)
- Rest - Same as above.
| Priority - High? Rationale:
Participant Operator Priority - AT&T - ?
- Reliance Jio - ?
- Verizon - ?
- Vodafone - ?
| Priority - Medium? Rationale:
Participant Operator Priority - AT&T - ?
- Reliance Jio - ?
- Verizon - ?
- Vodafone - ?
| - Use Existing VPCs (VPC creation out of scope for ONAP)
- Rest- Same as above.
| Priority - Medium? Rationale:
Participant Operator Priority - AT&T - ?
- Reliance Jio - ?
- Verizon - ?
- Vodafone - ?
| Priority - Medium? Rationale:
Participant Operator Priority - AT&T - ?
- Reliance Jio - ?
- Verizon - ?
- Vodafone - ?
|