- Microservices: ONAP modules should be designed as microservices: service-based with clear, concise function addressed by each service with loose coupling.
| | | Architecture Principles (New) |
- Shared Services: Where applicable, reusable components can be provided as shared services across ONAP components.
| | | Architecture Principles (New) |
- CI / CD Support: ONAP is predicated on an accelerated lifecycle for network services. As such, agility is key in all aspects of ONAP: development of ONAP, designing of network services, and operation of both ONAP and network services. Principles of continuous integration and deployment should be followed by all modules of the ONAP platform.
| | | Architecture Principles (New) |
- 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) |
