ONAP must support a complete life cycle management of software-defined network functions and services:

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.

ONAP should define a standardized common information model for complete life cycle management that all vendors must follow.  This will allow ONAP users to quickly onboard and support new resources (xNFs) and/or services.

ONAP must strive to support a common approach to manage various network functions from different vendors and provide vendor clear guidelines for vendor to follow:

All meta-data / artifacts required by various ONAP components should be designed from a central ONAP design studio, cataloged and shared from central repository.

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 automation should be policy driven, allowing users to dynamically control automation behavior via policy changes without recompiling ONAP code.

All ONAP components (SO, AAI, etc) should be model-driven, avoiding, where possible, programming code (Model driven APIs and model driven behavior).  This allows for a catalog-based reusable repository for network & services lifecycle management.

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.

When an ONAP component relies on software outside of the ONAP project, the dependency on that external software should be designed to be pluggable, API-oriented, supporting multiple possible implementations of that dependency.

 ONAP platform should be able to run and support multiple cloud environments (simultaneously), including container environments like Kubernetes and other Cloud Native technologies.

Every new ONAP platform release should support backward compatibility with at least one previous release a described in the ONAP Common Versioning Strategy.

ONAP modules should be designed as microservices: service-based with clear, concise function addressed by each service with loose coupling.
Support extensive use of microservices as a means of supporting (a) loosely-coupled agile development, test, and deployments, (b) runtime scalability, resilience, and decreased footprint, and (c) feature reusability

Where applicable, reusable components can be provided as shared services across ONAP components.

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.

Various service providers and users of ONAP should be able to quickly integrate ONAP with their existing OSS / BSS systems. An open, standards-based architecture with well-defined APIs fosters interoperability both within ONAP and across complementary projects and applications

Define ONAP as a layered architecture similar to the OSI model for the internet. ONAP will have an orchestration layer, multi-cloud layer, and application control and lifecycle management layer.  These layers interface with each other using defined abstract interfaces between the different layers to support information and request flowing between the layers in an implementation-independent manner.

Defines an abstract data model of the objects and entities to be managed by ONAP.