...
- 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.
- 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 every new release.
...
- Cloud Environment Support: All components in ONAP should be virtualized, preferably with support for both virtual machines and containers. All components should be software-based with no requirement on a specific hardware platform.
- Scalability: ONAP must be able to manage a small set of PNF / VNFs to highly distributed, very large network and service environment deployed across the globe. It should be possible to deploy multiple instances of ONAP and create a network of inter-working ONAP instances.
- Availability & Resiliency: ONAP must support various deployment and configuration options to meet varying availability and resiliency needs of various service providers.
- Security: All ONAP components should keep security considerations at the fore-front of all architectural decisions. Security should be a pervasive underlying theme in all aspects of ONAP. The ONAP architecture should have a flexible security framework, allowing ONAP platform users to meet their security requirements.
- Platform Plumbing: Identifies areas of commonality and implements reusable solutions that can be used to support generic needs such as (a) resiliency and traffic control, (b) observability, (c) security, and (d) data persistence, alleviating the burden of this on the module developers, and speeding up the process accordingly. This also helps optimize platform and component footprint.
Mind map diagram above maintained in ONAP Architecture Principles and Notes.xmind
...