ONAP ETSI Alignment Update presentation to the ETSI NFV on September 15th
Honolulu+ Priorities Discussion
Requirements
- Onboard ETSI SOL004 compliant VNF/CNF packages (ETSI Package Management)
- Support for extended VNFD, Helm Charts, Container Images/references, based on IFA 011
- SOL001 VNF/CNF mapping to SDC AID DM (including Policy Aspect/VF-Module, VDU/VFC)
- Enhance AAI Schema for CNF topologies for granting
- Onboarding VNFD with configuration properties
- Design ETSI SOL007 compliant Network Service Descriptor packages (ETSI Package Management)
- SOL001 NS mapping to SDC AID DM
- Generate SOL007 NS package to the "ETSI_PACKAGE" directory
- Onboard ETSI SOL007 3.3.1 compliant Network Service Descriptor packages (ETSI Package Management) - stretch goal
- SOL001 NS mapping to SDC AID DM
- Preserve the original vendor NS package to the "ETSI_PACKAGE" directory
- Support for Nested/Hierarchical ETSI SOL001 Network Service Descriptor - stretch goal
- Support for ETSI SOL003 Or-Vnfm Interface from ONAP to external VNF Manager(s)
- Enhance the SOL003 Adapter to support VNFM VNF/CNF orchestration
- Support for ETSI SOL005 Os-Ma-nfvo interface between ONAP and NFVO
- Support invocation of NFVO (SO NFVO, VFC, External NFVO) based on modeling thru SOL005 APIs
- Enhance SO E2E Workflows for collecting parameters for NS requests
- Support for ETSI Package distribution including Software and Container Images
- Enhance ETSI Catalog Manager to push Container Images to CIR
- Support Or-Vi for Software Image management
- Support for ETSI NFV NFVO Orchestrator in ONAP SO
- Support ETSI SOL005 and SOL003 APIs including subscription and notification
- Support Dynamic BPMN Workflows (ability to deploy custom NFVO BPMN workflows and logic which SO is running)
- OOF-based resource Granting for Instantiation and Termination
- Support for ETSI-based Application Configuration (for VNF) - post Honolulu?
- Design CBA and attach it to SDC CSAR for CDS-based configuration
- Enhance SO NFVO to leverage CDS and SDNC, support VNF application configuration
- Onboarding VNFD with configuration properties
- Support the Modify Configuration APIs from SOL005/SOL003 Adapters
- Note: expect VNFM supports the Modify Configuration APIs
- Scaling and Healing support is NOT part of Honolulu
Architecture
Model-driven CNF LCM Orchestration
The following diagram depicts model-driven CNF LCM orchestration.
CNF Support Architecture
The following diagram depicts ETSI-based CNF support Architecture.
CNF Support
- CNF Support is one of Ericsson’s highest priority work items for ONAP
- Define a fast path to CNF support, and accomplish it across multiple releases (Honolulu+)
- For now, leverage currently available ETSI Stage 2 specifications, without just waiting for ETSI Stage 3 (SOL)
- Many (Ericsson, Verizon, Bell Canada, Huawei, others) believe the target is CNF, 5G Edge, etc. VNF support is a steppingstone towards that goal
- CNF support and Cloud Native Support are closely related.
- CNF enables Cloud Native (Microservices, Containers, Elastic scalability, On-demand deployment)
- What other Cloud Native support? APs: Define its scope and study architecture
- In Honolulu, CNF scope is:
- CNF modeling and distribution support for microservice-based CNF and images,
- CNF LCM through SO, SO NFVO (or VFC) and VNFM via standard APIs (covering instantiation and Day 0 configuration based on Helm Charts)
- Note: VNFM support for CNF is vendor-specific
- OOF-based Granting only for both VNF/CNF Instantiation and Termination, not for VNF/CNF Healing or Scaling
- Software Images and Container Image Handlings via NFVO, ETSI Catalog Manager and CIR
- Collaborate with non-ETSI-based CNF support in SO; SO launches the CNF LCM path based on models (i.e., model-driven)
Configuration Support Architecture
This following diagram depicts ETSI-based Configuration support.
- Leverage CBA design and SDC distribution (CBA + CSAR) for model-driven configuration
- Leverage existing CDS, SDNC / MultiCloud path, or new ETSI-based configuration support thru Ve-Vnfm (SOL002)