Status: Draft.TSC approval
TSC Approval Date:
Readme: To be removed when this is recomended:
This is a place to capture the Architecture principles. There are other architecture principles wiki pages which should be leveraged. They will be deprecated when this is considered mature.
In particular this will leverage and depricate the following wikis:
September 19th, 2019
1. Architecture Principles Purpose:
...
- 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:
...
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:
...
4.2.2 Model Driven:
All ONAP modules 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.
...
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
...
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
...
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.
...
Platform System Data Model:
Defines an abstract data model of the objects and entities to be managed by ONAP.
...
| Gliffy | ||||
|---|---|---|---|---|
|
6. Architecture Way of Working & Process
The following page describes the Architecture Way of Working and Process: