...
Deployment Model | Edge using certain ONAP management workload functions as an Offload | |
| Description | Architecture Near-term Priority | |
Edge and Central Provider are same |
| Priority - High? Rationale:
Note: Analytics is currently addressed by a Distributed DCAE Orchestrator based on Cloudify. Participant Operator Priority
|
Edge and Central Providers are different |
| Priority - High? Rationale - Same as above. Participant Operator Priority
|
Managed Workloads
...
Deploy-ment Model
- Managed workload instantiation is always started by ONAP Central components
- If "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.
...
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:
- Same as above.
Participant Operator Priority
- AT&T - ?
- Reliance Jio - ?
- Verizon - ?
- Vodafone - ?
Priority - Medium?
Rationale:
- Same as above.
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:
- Same as above.
Participant Operator Priority
- AT&T - ?
- Reliance Jio - ?
- Verizon - ?
- Vodafone - ?
Priority - Medium?
Rationale:
- Same as above.
Participant Operator Priority
...
- " as described in the previous table, the corresponding workload LCM functions will be taken care of by offloaded ONAP management components
- " as described in the previous table, the corresponding workload LCM functions will be taken care of by offloaded ONAP management components
No change is envisioned in the workload instantiation from a ONAP user perspective.