Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »


(from Architectural principles_v3.docx)

Architectural principles provide guidelines when making architecture decisions.  The principles are not requirements (functional or non-functional), nor should they specify the design of the system.


1.    ONAP Scope:

  • Lifecycle Support: ONAP must support a complete life cycle management of software-defined network functions / services: from VNF On-Boarding, Service Definition, VNF/Service Instantiation, Monitoring, Upgrade, to retirement
  • Standardization: ONAP must support a common approach to manage various network functions from different vendors
  1. Standard templates for instantiations
  2. Standard language for configuration
  3. Standard telemetry for monitoring and management
  • Vendor & Service Agnostic: ONAP Platform must be VNF, Resources, Products, and Service agnostic. Each service provider or integrator that uses ONAP can manage their specific environment (Resources, VNFs, Products, and services) by creating necessary meta-data / artifacts using Design Studio to support their needs / environment.
  • Common Information Model approach:  ONAP should define a standardized common information model for all vendors to follow.  This will allow ONAP users to quickly onboard and support new VNFs.
  • Pluggable Modules: The ONAP architecture should develop and promote VNF standards to allow delivery of Lego block-like pluggable modules, with standard interfaces for all aspects of lifecycle management (e.g. instantiation, configuration, telemetry collection, etc.).
  • Integrated & Centralized Design Studio:  All artifacts required for ONAP components should be able to be designed from a central ONAP design studio.

2.    Business Imperatives to Address:

  • ONAP must support Automation at every phase of Lifecycle
  • Model Driven: All ONAP modules should be model-driven, avoiding, where possible, programming code.  This allows for a catalog-based reusable repository for network & services lifecycle management.
  • Meta-data & 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 automations should be policy driven, allowing users to dynamically control automation behavior via policy changes.
  • 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.
  • Integration Friendly: When an ONAP component relies on software outside of the ONAP project, the dependency on that external software should be designed to pluggable, API-oriented, supporting multiple possible implementations of that dependency.
  • Multi-tenancy managed environment: The ONAP platform should support the ability manage multiple tenants and provide isolation for those tenants.
  • Backward Compatibility: ONAP platform should support backward compatibility with every new release.

3.     ONAP Implementation Approach:

  • Microservices: ONAP modules should be designed as microservices: service-based with clear, concise function addressed by each service with loose coupling.
  • Shared Services:  Where applicable, reusable components can be provided as shared services across ONAP components.
  • 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.
  • Integration Friendly / Standard API:  Various service providers and users of ONAP should be able 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 

4.     ONAP Deployment / resiliency / scalability Support:

  • a.    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.
  • b.    Scalability: ONAP must be able to manage a small set of VNFs to highly distributed, very large network and service environment deployed across the globe.
  • c.    Availability & Resiliency: ONAP must support various deployment and configuration options to meet varying availability and resiliency needs of various service providers.
  • d.    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.




Mind map diagram above maintained in ONAP Architecture Principles and Notes.xmind

See also Draft Architecture Principles

  • No labels