...
- Model Driven: All ONAP modules should be model-driven, avoiding, as much as possible, new programming code. This allows for a catalog-based reusable repository for resources, network & services lifecycle management.
- Meta-data & Policy Driven Automation: ONAP should support high levels of automation at every phase of lifecycle management – e.g. onboard, design, deployment, instantiation, upgrade, monitoring, management, to end of life cycle. These automations should be policy driven, allowing users to dynamically control automation behavior via policy changes.
- Self-Service & User Focused: ONAP Platform should support a self-service model with a fully integrated user-friendly design studio to design all facets of lifecycle management (resources / service design, operational automation, etc.). All interfaces and interactions with ONAP should be user friendly and easy to use.
- Integration Friendly: When an ONAP component relies on software outside of the ONAP project, the dependency on that external software should be designed to pluggable, API-oriented, supporting multiple possible implementations of that dependency.• The
- The ONAP APIs are clearly documented and independent of the ONAP component implementation technologies (messages, procedures and contract).
- The ONAP APIs are forward and backwards compatible.
- Cloud Agnostic: ONAP platform should be able to run and support multiple cloud environments (simultaneously), including container environments like Kubernetes and other Cloud Native technologies.
- Backward Compatibility: Every new ONAP platform release should support backward compatibility with at least one previous release.
...