...
- VNF modeling with minimum CNF enhancements from ETSI NFV 4.1.1, by conforming to the ETSI SOL004 Package and SOL001 Modeling standards
- automated NSD and VNF/CNF package E2E distribution, by conforming to SOL005 and SOL003 Package Management APIs
- NS and VNF Orchestration through a modular architecture and standards-based (ETSI NFV) interfaces, by conforming to SOL005 and SOL003 LCM standards
1.1 Overall Architecture
The following diagram depicts overall ETSI-Alignment Architecture for Honolulu.
- SDC supports SOL004 Package onboarding
- SDC supports SOL007 Design
- SOL007 Onboarding is not yet supported in Honolulu
- ETSI Catalog Manager receives SDC Package notification
- ETSI Catalog Manager gets the original vendor ETSI NS and VNF packages and stores them into its database
- ETSI Catalog Manager sends the package onboarding notification to its subscribers (SO NFVO, SOL003 Adapter, in the future SOL005 Adapter)
- If the SOL004 VNF package embeds Container Images, ETSI Catalog Manager pushes the images to CIR via Docker Registry APIs
- Currently, ETSI Catalog Manager defined this Container Image handling as a stretch goal
- If not (due to SDC 2MB Image file size limitation), ETSI Catalog Manager does not handle Container Images. In that case, the operator will upload Container Image(s) to the CIR component directly
- SOL004 Package metadata will references Container Image file(s)
- CIR will be realized by Nexus with Docker Registry
- CIR component can be delivered part of ONAP or the operator can leverage their CIR component(s)
- Access APIs to CIR will be Docker Registry APIs
- K8S CISM will obtain information on Container Image(s) thru Docker Registry APIs
- K8S CIS will pull Container Image(s) thru Docker Registry APIs
- The Interface between VNFM and K8S CISM will follow K8S APIs
- Interface between VNFM and CISM: use k8s APIs, potential to leverage an alignment with O2-DMS
- Interface between MultiCloud K8s Plugin and CISM: use k8s APIs, potential to leverage alignment with O2-DMS
- VNFM Enhancement (PoC) to invoke CISM on O-Cloud through O2-DMS
- Note: support O2-DMS is a stretch goal; most likely use K8S APIs
1.2 ONAP SO CNF Orchestration Support
There are two tracks in ONAP for CNF support: ONAP ETSI-Alignment and Direct Path for CNF (Based on models, SO selects a proper path):
- ETSI-Alignment path
- Following ETSI NFV IFA specifications for CNF
- Leveraging and extending existing ONAP ETSI-Alignment Architecture
- Direct Path
- Some think there is no need for the full VNFD for LCM, just Helm Charts and Images; delegate LCM to CISM; it may work for simple CNFs
- Note: there are several cases where a more complete VNFD will be needed, such as 5G Core NFs.
- Collaboration Areas:
- Unified Modeling, Packaging & Onboarding (SDC) – optional VNFD?
- Package Distribution (SDC – ETSI Catalog Manager – CIR)
- Common Components (e.g., CIR, A&AI, CDS)
- Note: CIR will be realized by Nexus with Docker Registry, and CIR access APIs will be based on Docker Registry APIs.
2- New component capabilities for Honolulu, i.e. the functional enhancements, if applicable
...