Versions Compared

Key

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

...

...

Organization Mgmt, Sales Strategies: There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. 


ONAP

...

high level design principles requirements 

Key ContactsAlessandro D'Alessandro, ceciliamaria.corbi@telecomitalia.it 

Executive Summary – Today new emerging infrastructures based on kubernetes are becoming very popular. ONAP components shall support CNAs/CNFs artifacts and , cloud native service models and relevant distribution/management. Given the fact that K8s has its own orchestration capabilities that partially overlap with ONAP capabilities, it is expected that ONAP developments will focuse only development focuses first on aspects not covered by K8s. The envisioned scenario is based on both CNFs (deployed on kubernetes infrastructure) and PNFs. Business Impact – Today, many ONAP components (e.g. SDC, SO and AAI) are not able to manage CNA artifact/service models in a native way that bring to unnecessary complexity in service orchestration. It is expected that ONAP modeling and LCM support services composed of PNFs and CNFs to be future proof. ONAP developments will focuse only Moreover kubernetes provide a declarative approach to the orchestration of many aspects such as resource provisioning, resource scaling and resiliency and can be enhanced with many add-ons that seamlessly provide other features such as application control, communication robustness etc (e.g service mesh by Istio).  ONAP provides a good level of flexibility in service orchestration (e.g. a la carte, Macro and E2E orchestration approaches) but the framework requires specialized skills to implement unforeseen orchestration patterns that may slow down new service design and deployment. It is therefore required that ONAP functional module adopts a declarative approach and native support for CNAs artifacts to avoid time to market bottlenecks. Link 20200512.ONAP.relG.TIM.functional.requirements.pptx

Business Impact – Today, many ONAP components (e.g. SDC, SO and AAI) are not able to manage CNA/CNF artifact/service models in a native way that bring to unnecessary complexity in service orchestration. It is expected that ONAP modeling and LCM support be future proof. ONAP developments shall focus first on LCM aspects not covered by K8s (e.g. mainly on service orchestration rather than resource orchestration, resource splitting among different k8s clusters, PNF, etc.).

Business Markets - All operators and service providers that are using ONAP for service and network function Life Cycle Management

Funding/Financial Impacts – Native support of Cloud native Apps artifacts/service models allow workforce skills reduction and hence OPEX reduction requires custom development before introducing ONAP in production environment with CAPEX expenditure

Organization Mgmt, Sales Strategies - There is no additional organizational management or sales strategies for this use case outside of a service provider "normal" ONAP deployment and its attendant organizational resources from a service provider.

 

Support for a declarative approach in the SO engine

...

Business Impact – Today, ONAP service orchestrator requires specialized skills to implement unforeseen orchestration patterns or to modify implemented workflows. A declarative SO engine enables opex savings.

Business Markets - All operators and service providers that are using ONAP for service and network function Life Cycle Management

Funding/Financial Impacts – The usage of declarative engine allows to reduce the workforce skills required to manage the platform and reduce the time to market for service introduction. That ends up in OPEX reduction

Organization Mgmt, Sales Strategies - There is no additional organizational management or sales strategies for this use case outside of a service provider "normal" ONAP deployment and its attendant organizational resources from a service provider.

 

Support for easy A&AI schema modification

Executive Summary - Emerging cloud infrastructures based on kubernetes provide a comprehensive toolset for managing cloud native resources in a fast and efficient way. ONAP shall have to be fast and efficient at the same pace. That means that every bottleneck should be avoided in the introduction of a new service and therefore it is expected that inventory schema may be changed easily every time it is required.

Business Impact – Today, ONAP A&AI schema changes requires high-level operational expertise because of the impacts on the whole platform with high operational costs.

Business Markets - All operators and service providers that are using ONAP for service and network function Life Cycle Management

Funding/Financial Impacts – The usage of solutions that enable easily A&AI schema changes allows to reduce the workforce skills required to manage the platform and reduce the time to market for service introduction. That ends up in OPEX reduction

Organization Mgmt, Sales Strategies - There is no additional organizational management or sales strategies for this use case outside of a service provider "normal" ONAP deployment and its attendant organizational resources from a service provider.

  

Support for A&AI and k8s alignment about instance details that need to be kept in A&AI

Executive Summary – Today new emerging infrastructures based on kubernetes are becoming very popular. ONAP inventory shall support the representation of instances information related to such new infrastructures. Nevertheless, such cloud infrastructures likely do not require a detailed instance representation in the inventory because of the native orchestration capabilities and hence a detailed investigation is required because the solution may differ from the one used for Openstack based infrastructure

Business Impact – Today, ONAP A&AI is not able to correctly represent instances information related to kubernetes infrastructures so limiting the actual usage of ONAP for cloud native infrastructures.on resource splitting among different k8s clusters rather than on single k8s cluster, on PNFs LCM aspects , etc.). Moreover it is required that ONAP be designed in a way that it can be easily be customized with general programming skill personel.  

Business Markets - All operators and service providers that are using ONAP for service and network function Life Cycle Management

Funding/Financial Impacts Lack of such functionality Native support of Cloud native Apps artifacts/service models allow workforce skills reduction and hence OPEX reduction requires custom development before introducing ONAP in production environment with CAPEX expenditure

...