Page History

...

ONAP SO Hierarchical Orchestration Architecture

The following diagram depicts ONAP SO hierarchical orchestration architecture.

ONAP SO NFVO Function Overlap View in ETSI MANO

• The following diagram depicts the SO NFVO position in ETSI MANO.

Image Removed

NSD Structure that is supported by NS LCM

• The following diagram depicts the NSD structure that NS LCM supports.
• VNF-FG is out of scope from Guilin.

Image Removed

ONAP SO NFVO Architecture & Functions

Component Diagram

The following diagram depicts the NFVO component architecture

• NFVO Microservice Plugin Platform provides Microservice registration, discovery and routing.
• Microservice registration will be performed by configuration.

Note:

• we are not building the Microservice service registration, aggregation, discovery and routing engine itself, but we are leveraging the engine's capability (e.g., MSB, API Fabric, Kong, or Kubernetes & service discovery) to offer configuration of NFVO Microservice components access. So, the NFVO Microservice Plugin Platform is the engine + NFVO component configuration.
• If dynamic BPMN deployment is not available in Guilin, it is possible the NS Workflows embed Camunda Engine for Guilin, as a Microservice.
  
  • In the dynamic BPMN deployment case, the NS Workflows would be a WAR file, containing NS BPMNs + Business Logic, and deployed into Camunda Engine.

SO NFVO Sub-Components

• SOL005 NBI Handler
• NS LCM Manager
• NS Workflows & Business Logic
• Shared Camunda Engine
• RIM (Resource Infra Management) Manager
• SOL003 Adapter
• Inventory DB Adapter (for AAI)
• NS LCM DB
• Catalog DB Adapter (for ETSI Catalog Manager)
• MultiCloud Adapter (for MultiCloud)
• Configuration Adapter (not for Guilin)
• Policy Adapter (not for Guilin)
• FM/PM Event Manager (not for Guilin)
• K8S Adapter (not for Guilin)

Component Interfaces

The following diagram depicts component interfaces. 

Note: the blue lines represent interfaces within SO NFVO, and the black lines represent NFVO component interfaces with other ONAP components.

Rationale & Benefits

Rationale

Many operators have their own ETSI-compliant NFVOs, and there is a strong desire for us to have both ETSI- and ONAP-compliant NFVO.  So, we propose the ONAP SO NFVO "platform", which is based on ONAP and leveraging modular and extensible plugin-based microservice API management, such as an enhanced MSB, Gravitee, Kong or Kubernetes. Once we build this NFVO platform in ONAP, operators including us can focus on the proprietary development of truly differentiating value-added capabilities on top of the NFVO platform. We believe this approach provides cost saving over implementation of proprietary code, both for initial development, ongoing standardization support and enhancements.

Note: VFC would be still a valid NFVO reference implementation. And, we want to have this NFVO platform which provides modular and extensible capabilities. 

Benefits

...

Rationale & Benefits

Rationale

Many operators have their own ETSI-compliant NFVOs, and there is a strong desire for us to have both ETSI- and ONAP-compliant NFVO.  So, we propose the ONAP SO NFVO "platform", which is based on ONAP and leveraging modular and extensible plugin-based microservice API management, such as an enhanced MSB, Gravitee, Kong or Kubernetes. Once we build this NFVO platform in ONAP, operators including us can focus on the proprietary development of truly differentiating value-added capabilities on top of the NFVO platform. We believe this approach provides cost saving over implementation of proprietary code, both for initial development, ongoing standardization support and enhancements.

Note: VFC would be still a valid NFVO reference implementation. And, we want to have this NFVO platform which provides modular and extensible capabilities. 

Benefits

• Boosts industry compatibility by leveraging ETSI compliant models, interfaces and package management
• Provides pluggable NFVO functional blocks that are modular and extensible
• Enables Operators to focus on the proprietary development of truly differentiating value-added capabilities on top of ONAP SO NFVO
• Provides cost saving over implementation in proprietary code, both for initial development, ongoing standardization support and enhancements

Hierarchical Orchestration Architecture

The following diagram depicts ONAP SO hierarchical orchestration architecture.

ONAP SO NFVO Function Overlap View in ETSI MANO

• The following diagram depicts the SO NFVO position in ETSI MANO.

Image Added

NSD Structure that is supported by NS LCM

• The following diagram depicts the NSD structure that NS LCM supports.
• VNF-FG is out of scope from Guilin.

Image Added

ONAP SO NFVO Architecture & Functions

Component Diagram

The following diagram depicts the NFVO component architecture

• NFVO Microservice Plugin Platform provides Microservice registration, discovery and routing.
• Microservice registration will be performed by configuration.

Note:

• we are not building the Microservice service registration, aggregation, discovery and routing engine itself, but we are leveraging the engine's capability (e.g., MSB, API Fabric, Kong, or Kubernetes & service discovery) to offer configuration of NFVO Microservice components access. So, the NFVO Microservice Plugin Platform is the engine + NFVO component configuration.
• If dynamic BPMN deployment is not available in Guilin, it is possible the NS Workflows embed Camunda Engine for Guilin, as a Microservice.
  
  • In the dynamic BPMN deployment case, the NS Workflows would be a WAR file, containing NS BPMNs + Business Logic, and deployed into Camunda Engine.

SO NFVO Sub-Components

• SOL005 NBI Handler
• NS LCM Manager
• NS Workflows & Business Logic
• Shared Camunda Engine
• RIM (Resource Infra Management) Manager
• SOL003 Adapter
• Inventory DB Adapter (for AAI)
• NS LCM DB
• Catalog DB Adapter (for ETSI Catalog Manager)
• MultiCloud Adapter (for MultiCloud)
• Configuration Adapter (not for Guilin)
• Policy Adapter (not for Guilin)
• FM/PM Event Manager (not for Guilin)
• K8S Adapter (not for Guilin)

Component Interfaces

The following diagram depicts component interfaces. 

Note: the blue lines represent interfaces within SO NFVO, and the black lines represent NFVO component interfaces with other ONAP components.

...

Requirements

Support for ETSI NFV NFVO  Orchestrator in ONAP SO (ONAP SO ETSI-Aligned Hierarchical Orchestration)

...