Status: TSC approval

TSC Approval Date: September 19th, 2019

1. Architecture Principles Purpose:

The purpose of the architecture principles is to provide guidelines for both the developement and evolution of the ONAP architecture at an overall level, but also for the evolution of the project architectures.

2. Principles Modifications

Each Principles is numbered.  Do not renumber the principles in case they are references.  A removed principle is replace with VOID.

3. Architecture Principles Structure

The Architecture principles below are strucutured into four parts:

• Scope of the ONAP platform
• Key guiding imperatives for ONAP modules
• Implementation Principles
• Deployment, Resiliencey and Scalability considerations

4. The ONAP Architecture Principles

4.1 ONAP Architecture Principles: Scope

4.1.1 Lifecycle support:

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

• VNF and PNF onboarding
• Service onboarding
• Service definition
• Service update
• VNF, PNF and service instantiation
• VNF, PNF and service instance upgrade
• VNF, PNF and service instance monitoring
• VNF, PNF and service instance autonomous repair / optimization
• VNF / PNF / service instance retirement

4.1.2 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.

4.1.3 Common Information Model approach:

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.

4.1.4 Strive for Standardization: 

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:

• • Standards for PNF / VNF Packaging, templates for instantiations and life cycle management
  • Standard language for configuration of network / services
  • Standard telemetry for monitoring and  management
  • Pluggable Modules: The ONAP architecture should develop and promote xNF standards to allow delivery of Lego block-like pluggable network function modules, with standard interfaces for all aspects of lifecycle management (e.g. instantiation, configuration, telemetry collection, etc.).  This will allow ONAP users to on-board new network function and use it with minimal customization and development.

4.1.5 Integrated & Centralized Catalog:

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

4.2 ONAP Architecture Principles: Business Imperatives (i.e. User Community Requirements)

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

4.2.2 Model Driven:

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.

4.2.3 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.

4.2.4 Integration Friendly:

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.

• • Use of microservices will require documented interfaces to be supported and provide reference implementations, both of which will make creation of alternate versions easier

4.2.5 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.

4.2.6 Backward Compatibility:

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

4.3 ONAP Architecture Principles: Implementation Approach

4.3.1 Microservices:

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

4.3.2 Shared Services:

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

• • Build out the common services as part of a shared platform, supporting (a) common platform services (e.g. security), (b) data management (e.g. logging), and (c) intra-platform communications (e.g. traffic controls and tracing)
  •  Provide common tooling that can be used by microservices to support standard functionality for resiliency, traffic control, observability and security (viz. service meshes)

4.3.3 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.

• • Extend and support current CI/CD standards and implementations to support agile development and deployment of individual microservices and introduction of same in a controlled manner

4.3.4 Integration Friendly / Standard API:

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

• • Use of microservices will require documented interfaces to be supported and provide reference implementations, both of which will make creation of alternate versions easier. Integration with non-ONAP components similarly facilitated by defining all ONAP APIs interfacing externally.

4.3.5 Layered Software Abstractions:

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.

4.3.6 Platform System Data Model:

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

4.4 ONAP Architecture Principles: Deployment / Resiliency / Scalabiilty Support

4.4.1 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.

• • Component refactoring to address current problems will extend the use of microservices, service meshes and cloud-native technologies, moving to a fuller implementation of this principle

4.4.2 Scalability:

ONAP must be able to manage a small set of xNFs to highly distributed, very large network and service environment with millions of managed resources deployed across the globe.

• • Some of refactored microservices could be ephemeral, supporting scalability through dynamic instance creation, movement, restart, and teardown

4.4.3 Availability & Resiliency:

ONAP must support various deployment and configuration options to meet varying availability and resiliency needs of various service providers.

• • Some of refactored microservices could be ephemeral, supporting scalability through dynamic instance creation, movement, restart, and teardown
  • Should strive for 'hitless' upgrade/downgrade or insertion of external microservices

4.4.4 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.

• • Enhance security by decoupling development from the components and modules by providing features as a common service, sidecar or pluggable module. Support enhanced & automated key rotation and certificate management.

4.4.5 Platform Plumbing:

Identifies areas of commonality and implements reusable solutions that can be used to support generic needs such as (a) resiliency and traffic control, (b) observability, (c) security, and (d) data persistence, alleviating the burden of this on the module developers, and speeding up the process accordingly.

       4.4.6 Lightweight & Modular Platform:

The ONAP footprint should be reasonable compared to the size of the managed network. ONAP should support a minimal footprint configuration as an entry level networks. The size of ONAP should not be an inhibitor for end user adoption. Large   managed networks may require larger deployment footprint.

ONAP must provide flexibility to deploy only selected component to meet user's scope and allow incrementally add components as scope increases (e.g. design and deploy basic resources / services, Add application level configuration and lifecycle management, and finally add service assurance functions using DCAE and Policy).

4.4.7 Runtime Independence from Internet:

ONAP must be runnable in a completely private environment with no routing to Internet. This effectively means that any runtime downloading of libraries, definitions and resources from the internet is prohibited and everything must be packaged to the images of the ONAP installation package.

5 Architecture Principles Summary

6. Architecture Way of Working & Process

The following page describes the Architecture Way of Working and Process:

ONAP Architecture Team Process