Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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:

...

2. Principles Modifications

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

...

The Architecture principles below are strucutured into three into four parts:

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

...

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

...

Gliffy
13
nameArchitecture Principles Summary
pagePin16


6. Architecture Way of Working & Process

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

ONAP Architecture Team Process - Old