...
1. ONAP Scope:
- Lifecycle Support: ONAP platform must support a complete life cycle management of software-defined network functions / services: from VNF/PNF On-Boarding, Resources / Service Definition, VNF / PNF and Service Instantiation, MonitoringMonitoring & Management, Change Management, Software Upgrade, to retirement
- Standardization: ONAP must support a standardized common approach to manage various network functions from different vendors
...
- Vendor & Service Agnostic: ONAP Platform must be PNF / VNF, Resources, and Service agnostic. Each service provider or integrator that uses ONAP can manage their specific environment (Resources, PNFs / VNFs, and services) by creating necessary meta-data / artifacts using Design Studio to support their needs / environment.
- Common Information Model approach: ONAP should define a standardized common information model for all vendors to follow. This will allow ONAP users to quickly onboard and support new PNF / VNFs and services.
- Pluggable Modules: The ONAP architecture should develop and promote PNF / VNF standards to allow delivery of Lego block-like pluggable modules, with standard interfaces for all aspects of lifecycle management (e.g. instantiation, configuration, telemetry collection, etc.) from various vendors.
- Integrated & Centralized Design Studio: All artifacts required for ONAP meta-data / artifacts required by various ONAP components should be able to be designed from a central ONAP design studio, catalogued and shared from central repository.
2. Business Imperatives to Address:
- Model Driven: All ONAP modules should be model-driven, avoiding, new programming code, 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 (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.
...
4. ONAP Deployment / resiliency / scalability Support:
- 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 PNF / 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.
...