...
Architectural principles provide guidelines when making architecture decisions. The principles are not requirements (functional or non-functional), nor should they specify the design of the system.
1. ONAP Scope:
- Lifecycle Support: ONAP must support a complete life cycle management of software-defined network functions / services: from VNF/PNF On-Boarding, Resources / Service Definition, VNF / PNF Service Instantiation, Monitoring, Change Management, Software Upgrade, to retirement
- Standardization: ONAP must support a common approach to manage various network functions from different vendors
...
2. Business Imperatives to Address:
- ONAP must support Automation at every phase of Lifecycle
- Model Driven: All ONAP modules should be model-driven, avoiding, where possible, new programming code, as much as possible. 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 (product/ 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.
- Multi-tenancy managed environment: The ONAP platform should support the ability manage multiple tenants and provide isolation for those tenants.
- Backward Compatibility: Every new ONAP platform release should support backward compatibility with every new release.
...
- a. 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.
- b. Scalability: ONAP must be able to manage a small set of VNFs to highly distributed, very large network and service environment deployed across the globe.
- c. Availability & Resiliency: ONAP must support various deployment and configuration options to meet varying availability and resiliency needs of various service providers.
- d. 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.
Mind map diagram above maintained in ONAP Architecture Principles and Notes.xmind
...