...
- ONAP is a layered architecture – Orchestration, Multi-Cloud, Controller, etc.
- Functional role of each layer should be well defined per the aforementioned architecture principles.
- ONAP should support integrated design studio to capture full life-cycle management models (TOSCA models for NF, simple / nested services augmented with BPMN, Policy / Analytic design models, etc.).
- ONAP Should Support Cloud Agnostic Model and Multi-Cloud adaption layer while hiding infrastructure details.
- ONAP Target Goal is: Modular, Model-driven, Microservices-based architecture.
- Models drive interfaces between layers/components.
- ONAP should define well-described and consistent NB-APIs at all layers.
- Keep flexible capability for commercial solution (no vendor lock-in).
- Agree to unified modeling for integration across all modules: VES in DCAE, Logging & monitor inside ONAP and more.
The latest architecture diagrams and functional description of individual components can be found atBelow is the latest R2+ architecture deck. It's also located at: https://wiki.onap.org/display/DW/Contributions
- py20171218 py20180102 ONAP R2+ Architecture Proposal Proposal
View file name py20171218 py20180102 ONAP R2+ Architecture Proposal (updated) (003)_contributors added.pptx height 250
Architecture Tiger Team Weekly Meeting
...