/
ONAP SO ETSI-Aligned Hierarchical Orchestration

ONAP SO ETSI-Aligned Hierarchical Orchestration

Sept 25, 2020

Table of Contents

 

ETSI Standard Conformation

This proposal conforms to the following ETSI v2.7.1 specifications.

 

Resource commitment:

  • Ericsson: primary contact @Byung-Woo Jun

  • CMCC: primary contact @Yan Yang, @Yuanhong Deng

  • Verizon: primary contact @Former user (Deleted)

  • Samsung: primary contact @Miroslaw Medrek

Requirement:

  • Ericsson: primary contact @Byung-Woo Jun

  • CMCC: primary contact @Yan Yang, @Yuanhong Deng

  • Verizon: primary contact @Former user (Deleted)

  • Samsung: primary contact @Miroslaw Medrek

  • Huawei: primary contact @Seshu Kumar Mudiganti

ONAP SO Hierarchical Orchestration Architecture

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.

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.

ONAP SO NFVO Architecture & Functions

Target Component Diagram (Not all will be implemented in Guilin)

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)

ONAP SO NFVO Component for Guilin

The following diagram diagram depicts ONAP SO NFVO Component for Guilin.

 

ONAP SO NFVO Component Deployment View

The following diagrams depict a deployment view of ONAP SO NFVO. There are Plan A and B. The Plan B provides a simpler deployment option and will support the NS Workflow BPMNs migration to the Stand-Alone shared Camunda engine (when ONAP SO support custom Workflow deployment).

Deployment View for Guilin

In the Guilin, SO NFVO will consist of the following PODs:

  • NS LCM Mgr

  • SOL003 Adapter

  • NS LCM DB Mgr (not for Guilin; designed to reuse the VFC NS LCM DB Mgr Microservice, but the VFC Microservice is not yet available for Guilin)

    • In Guilin, NFVO database follows ONAP SO Database mechanism.

  • Resource Infra Management Mgr (not for Guilin; designed to handle OOF-based resource granting and Or-Vi management, but the OOF-based granting is not available for Guilin)

 

Guilin SO NFVO Testing

The UUI - SO - E2E Workflows - NS Workflows - SOL005 Adapter sequences are not ready for Guilin. As a result, the Curl Command as the SO NFVO client allows to send SOL005-compliant requests to SO NFVO directly.

 

Microservice Component Registration

TBD

SOL003 Adapter Registration 

The SOL003 Adapter registers itself in the OOM installation

[oom.git] / kubernetes / so / charts / so-vnfm-adapter / templates / service.yaml

1 # Copyright © 2019 Nordix Foundation
2 #
3 # Licensed under the Apache License, Version 2.0 (the "License");
4 # you may not use this file except in compliance with the License.
5 # You may obtain a copy of the License at
6 #
7 #       http://www.apache.org/licenses/LICENSE-2.0
8 #
9 # Unless required by applicable law or agreed to in writing, software
10 # distributed under the License is distributed on an "AS IS" BASIS,
11 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
12 # See the License for the specific language governing permissions and
13 # limitations under the License.
14 apiVersion: v1
15 kind: Service
16 metadata:
17   name: {{ include "common.servicename" . }}
18   namespace: {{ include "common.namespace" . }}
19   labels:
20     app: {{ include "common.name" . }}
21     chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
22     release: {{ include "common.release" . }}
23     heritage: {{ .Release.Service }}
24   annotations:
25     msb.onap.org/service-info: '[
26       {
27           "serviceName": "{{ include "common.servicename" . }}",
28           "version": "v1",
29           "url": "/so/vnfm-adapter/v1",
30           "protocol": "REST",
31           "port": "{{.Values.service.externalPort}}",
32           "visualRange":"1"
33       }
34       ]'
35 spec:
36   type: {{ .Values.service.type }}
37   ports:
38     {{if eq .Values.service.type "NodePort" -}}
39     - port: {{ .Values.service.internalPort }}
40       nodePort: {{ .Values.global.nodePortPrefixExt | default .Values.nodePortPrefixExt }}{{ .Values.service.nodePort }}
41       name: {{ .Values.service.portName }}
42     {{- else -}}
43     - port: {{ .Values.service.externalPort }}
44       targetPort: {{ .Values.service.internalPort }}
45       name: {{ .Values.service.portName }}
46     {{- end}}
47   selector:
48     app: {{ include "common.name" . }}
49     release: {{ include "common.release" . }}

 

Also, it registers itself with MSB.

metadata:

    name: {{ include "common.servicename" . }}

    namespace: {{ include "common.namespace" . }}

    labels:

        app: {{ include "common.name" . }}

        chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}

        release: {{ include "common.release" . }}

        heritage: {{ .Release.Service }}

    annotations:

        msb.onap.org/service-info: '[

            {

                "serviceName": "{{ include "common.servicename" . }}",

                "version": "v1",

                "url": "/so/vnfm-adapter/v1",

                "protocol": "REST",

                "port": "{{.Values.service.externalPort}}",

                "visualRange":"1"

            }

        ]'

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.

 

Architecture Presentation Slide Deck and Approval

ONAP Architecture Subcommittee approved this architecture on June 16th 2020.

Implementation Plan For Guilin

  • Create NS NBI

  • Instantiate NS NBI

  • Terminate NS NBI

  • Delete NS NBI

  • Create NS Backend

  • Instantiate NS Backend

Requirements

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

Executive Summary - Enable E2E workflows by orchestrating ETSI NFV compliant Network Services and VNFs. This NFVO should provide an ETSI NFV SOL005 v2.7.1 NBI which can onboard ETSI NFV SOL004 and ETSI NFV  SOL007 v2.7.1 compliant packages which then can be Life Cycle Managed and monitored. This NFVO should use an ETSI SOL003 v2.7.1 SBI to invoke an external VNF Manager. 

Business Impact - Enables operators and service providers to use Industry standard Orchestration to deploy, manage and monitor network services. Industry compatibility.

Business Markets - All operators and service providers that are developing ETSI compatible Network Services especially for 5G Slicing where each Slice Subnet is associated with a Network Service 

Funding/Financial Impacts - Reduction in operations expense from using industry standard ETSI Orchestration.

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 SO NFVO Requirements for Guilin

ONAP SO NFVO is a sub-component of SO and provides ETSI NFV-compliant NFVO functions in ONAP, such as ETSI NFVO MANO 1) SOL007, SOL004 and SOL001 Modeling and Package, 2) SOL005-compliant NBI, 3) NS LCM and 4) SOL003-compliant SBI for VNFM invocation.

Note: 

For the ONAP SO NFVO, we plan to build:

1) the NFVO platform foundation,

2) SOL005 NBI (based on the forge.etsi.org SOL005 swagger files; we believe it is easy to upgrade for ETSI specification changes),

3) NS LCM Manager leveraging Camunda BPMN with custom workflows support (in the future, possibly design workflows from SDC and associate them with NS models – model-driven),

4) leveraging VFC NS Instance DB microservice and NS LCM business logic, and

5) CNF support hook. Since ONAP SO already has the SOL003 Adapter, for our project, at this time we don’t need VFC gVNFM and VNFM adapting mechanism. 

 

P1: Phase 1 (for Guilin)

P2: Phase 2 (post Guilin)

P3: Phase 3 (future release)

Requirement #

Requirement

Component

Phase

Requirement #

Requirement

Component

Phase

NFVO.R1

Provides a NFVO function Microservice plugin framework for hosting NFVO function components 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. 

Note: the engine choice is under discussion

  • Support for Microservice registration

    • The following default function Microservices will be plugged in: 

      • SOL005 NBI (API Handler)

      • NS LCM Manager

      • NS Workflows and Logic (deployable to Camunda Workflow Engine)

      • Shared Camunda Engine (if ONAP Dynamic BPMN is available)

      • Camunda Workflow Engine

      • ETSI Catalog DB Adapter

      • NS Resource Infra Management (RIM) Manager

      • SOL003 Adapter

      • MultiCloud Adapter (leverage SO MultiCloud Adapter)

      • Inventory DB Adapter (default: AAI)

      • Notification Manager (not for Guilin)

      • Policy Adapter (not for Guilin)

      • K8S Adapter (not for Guilin)

      • Configuration Adapter (not for Guilin)

      • FM/PM Event Adapter (not for Guilin)

  • Support for substitution of existing function plugins

    • Supports registration of a new substitution Microservice with version control (leverage a mechanism like AAI ESR/MSB/API Fabric/MSB/Kubernetes/Kong - TBD)

    • supports plug-in mechanism of substitution Microservices

    • Dynamic dispatching/launching plugin instances based on configuration/policy

  • Support for extension of existing function plugins

    • Default function plugin extension with version control

    • Dynamic dispatching/launching an extended plugin instance based on configuration/policy

  • Support for Service Discovery

  • Support for Inter-Service Communication

Microservice Plugin Framework

(configuration)

P1

NFVO.R2

Supports SOL005-compliant NS LCM (Network Service Lifecycle Management) NBI interfaces for its client such as ONAP SO or SOL005-compliant clients. In Guilin, the following operations will be supported

  • Create NS

  • Instantiate NS

  • Terminate NS

  • Delete NS

  • Get NS Operation Status

  • Subscription (Create, GET, Delete)

  • Sends Notification (as a client)

SOL005 NBI

P1

NFVO.R3

Supports the ETSI-compliant NS LCM. In Guilin, the following operations will be supported

  • Create NS

  • Instantiate NS

  • Terminate NS

  • Delete NS 

  • Subscription

NS LCM

P1

NFVO.R4

Sends SOL005-compliant NS LCM notifications to its subscriber, such as ONAP SO or SOL005-compliant clients

  • Send NS Notification

SOL005 NBI

P1

NFVO.R5

Manages (as a client) virtualized resources via interfaces (Or-Vi) exposed by the VIM

  • Software Image (P1)

  • Container Image Management (P2)

  • Resource Management, validation and authorization of NFVI resource requests (P2)

NS RIM Manager

P1

NFVO.R6

Supports Virtual Links and VNF-FG - NS LCM 

  • VLs (P1)

  • VNF-FGs (P2)

NS LCM

P1

NFVO.R7

Manages (as a client) virtualized resource management interfaces (SOL003) thru the existing SOL003 Adapter

  • Create VNFs

  • Instantiate VNFs

  • Terminate VNFs

  • Delete VNFs

  • Subscription

NS LCM, SOL003 Adapter

P1

NFVO.R8

Supports VNF Granting interfaces (SOL003) to the SOL003 Adapter 

  • Granting VNF with HPA, leveraging OOF (TBD)

NS LCM, NS RIM Manager, SOL003 Adapter

P1

NFVO.R9

Supports VNF lifecycle management (LCM) notifications (SOL003) to the SOL003 Adapter 

  • Provides SOL003-compliant Notification endpoint for the SOL003 Adapter

NS LCM, SOL003 Adapter

P1

NFVO.R10

Interfaces with ETSI Catalog Manager for SOL004 VNF/PNF and SOL007 NS packages

  • Queries packages (VNF/PNF/NS)

  • Queries descriptions (VNFD/PNFD/NSD)

  • Subscription

NS LCM

P1

NFVO.R11

Supports package management notification interfaces to ETSI Catalog Manager

  • Provides notification endpoints based on the ETSI Catalog Manager package management interfaces

NS LCM

 

NFVO.R12

Supports Communication Security, conforming SOL005 specification 

  • ONAP SO NFVO NBI supports HTTPS and Authentication/Authorization towards SO/SOL005 Adapter

  • ONAP SO NFVO SBI (through SOL003 Adapter) supports HTTPS and Authentication/Authorization towards SVNFMs

NS LCM, SOL005 NBI

P1

 

 

 

 

 

ONAP SO and SOL005 Adapter Requirements 

 

Requirement #

Requirement

Component

Phase

Requirement #

Requirement

Component

Phase

SOL005.A.R1

ONAP SO receives E2E (OSS Service-level) requests and parse them and invoke NS workflows per NS 

Sends SOL005 requests to the ONAP SO NFVO, as one of the choices (SO NFVO, VFC, External NFVO)

SOL005 Adapter