ONAP SO ETSI-Aligned Hierarchical Orchestration
Table of Contents
ETSI Standard Conformation
This proposal conforms to the following ETSI v2.7.1 specifications.
- SOL005: https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/005/02.07.01_60/gs_NFV-SOL005v020701p.pdf
- SOL003: https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.07.01_60/gs_NFV-SOL003v020701p.pdf
- SOL002: https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.07.01_60/gs_NFV-SOL002v020701p.pdf
- SOL004: https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/004/02.07.01_60/gs_NFV-SOL004v020701p.pdf
- SOL007: https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/007/02.07.01_60/gs_NFV-SOL007v020701p.pdf
- SOL001: https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/001/02.07.01_60/gs_NFV-SOL001v020701p.pdf
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:
{
"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 |
---|---|---|---|
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
| 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
| SOL005 NBI | P1 |
NFVO.R3 | Supports the ETSI-compliant NS LCM. In Guilin, the following operations will be supported
| NS LCM | P1 |
NFVO.R4 | Sends SOL005-compliant NS LCM notifications to its subscriber, such as ONAP SO or SOL005-compliant clients
| SOL005 NBI | P1 |
NFVO.R5 | Manages (as a client) virtualized resources via interfaces (Or-Vi) exposed by the VIM
| NS RIM Manager | P1 |
NFVO.R6 | Supports Virtual Links and VNF-FG - NS LCM
| NS LCM | P1 |
NFVO.R7 | Manages (as a client) virtualized resource management interfaces (SOL003) thru the existing SOL003 Adapter
| NS LCM, SOL003 Adapter | P1 |
NFVO.R8 | Supports VNF Granting interfaces (SOL003) to the SOL003 Adapter
| NS LCM, NS RIM Manager, SOL003 Adapter | P1 |
NFVO.R9 | Supports VNF lifecycle management (LCM) notifications (SOL003) to the SOL003 Adapter
| NS LCM, SOL003 Adapter | P1 |
NFVO.R10 | Interfaces with ETSI Catalog Manager for SOL004 VNF/PNF and SOL007 NS packages
| NS LCM | P1 |
NFVO.R11 | Supports package management notification interfaces to ETSI Catalog Manager
| NS LCM | |
NFVO.R12 | Supports Communication Security, conforming SOL005 specification
| NS LCM, SOL005 NBI | P1 |
ONAP SO and SOL005 Adapter Requirements
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 | P1 |
SOL005.A.R2 | Subscribes to ONAP SO NFVO for notifications
| SOL003 Adapter | P1 |
SOL005.A.R3 | Provides notification endpoint(s) to receive notifications
| SOL003 Adapter | P1 |