- Standard APIs: ONAP must support a rich set of external APIs (aligned with standard bodies such as MEF, TMF, etc., when possible) to easily integrate ONAP with external OSS / BSS as well as other management systems.
| | | Architecture Principles (New) |
- Layered Abstraction: Define ONAP as a layered architecture similar to the OSI model for the internet. Define abstract interfaces between the different layers to support information and request flowing between the layers in an implementation-independent manner. Such a layered architecture provides flexibility to swap technology or replace an individual ONAP module, if desired.
| | | Architecture Principles (New) |
- 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
| | | Architecture Principles (New) |
- 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.
| | | Architecture Principles (New) |
- Strive for Standardization: ONAP must support standardized common approach to manage various network functions from different vendors
| | | Architecture Principles (New) |
- 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.
| | | Architecture Principles (New) |
- 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.
| | | Architecture Principles (New) |
- Availability & Resiliency: ONAP must support various deployment and configuration options to meet varying availability and resiliency needs of various service providers.
| | | Architecture Principles (New) |
- 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.
| | | Architecture Principles (New) |
- 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.
| | | Architecture Principles (New) |
