...
- 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, Monitoring & Management, Change Management, Software Upgrade, to retirement
- Strive for Standardization: ONAP must support standardized common approach to manage various network functions from different vendors
...
- Resources, Vendors, & 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 StudioCentralized Catalog: All meta-data / artifacts required by various ONAP components should be designed from a central ONAP design studio, catalogued cataloged and shared from central repository.
2. Business Imperatives to Address:
...
- 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 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.
3. ONAP Implementation Approach:
...