Resource commitment:
- Ericsson: primary contact: Byung-Woo Jun
Usecase Lead:
Ericsson: Byung-Woo Jun
TSC Contact:
- Ericsson: Stephen terrill
Participating ONAP Projects:
- Implementation: SO, AAI, SDC (not in Dublin)
...
- JIRA ONAPARC-310
(SO Adapter which uses SOL003 to connect to S/G VNFM)Jira Legacy server System Jira serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key ONAPARC-310 - JIRA SO-1508 (SO SOL003 plugin support to connect to an external VNFM): Epic
- See the user stories below for other JIRA tickets
- JIRA ONAPARC-310
SO-ETSI Alignment Use Cases for Dublin
Leverage ETSI standards for VNF LCM in SO
Build SO VNFM Adapter
Use SOL003 APIs (2.5.1) for VNF LCM
Support operations such as create, instantiate, grant, terminate, LCN subscription and LCN
- Support of Delete VNF is a stretch goal in Dublin
Enhance SO BPMN workflows & recipes
VNF-level and VF-Module Building Block workflows, leveraging VNFM Adapter
Passing VNF LCM requests to VNFM using VNFM Adapter
- Note: the following is followings are candidates for the El Alto release.
Provide VNF package management for VNFM
Policy-based VNF scaling thru VNFM Adapter
SO VNFM Adapter Requirements for Dublin
A new SO sub-component, following ONAP Microservice Architecture
A Generic VNFM Adapter
, supporting SOL003-compliant SVNFMs- Support of remaining SOL003 APIs
for VNFM LCM- VNF Package handling (Download & Parse VNF Package)
- Get package files from the SDC repository thru SO
- Provide VNF package(s), VNFDs and Artifacts to VNFM
- SO Catalog DB enhancement for SOL001/SOL004 is identified as future release work
- VNF Package handling (Download & Parse VNF Package)
SO VNFM Adapter Requirements for Dublin
A new SO sub-component, following ONAP Microservice Architecture
A Generic VNFM Adapter, supporting SOL003-compliant SVNFMs
- Support of SOL003 APIs for VNFM LCM
- Invoking SVNFM based on SOL003 VNF LCM APIs as a client
use https://forge.etsi.org/gitlab/nfv/SOL002-SOL003/2.5.1/master/src/SOL003/VNFLifecycleManagement swagger to generate a client
support Create VNF, Instantiate VNF, Terminate VNF operations as a client
collect data for SOL003 API parameters from SDNC, A&AI and OOF (for models with homing: OOF-based granting might be supported in El Alto)
- Granting, based on ETSI VNFLifecycleOperationGranting
use https://forge.etsi.org/gitlab/nfv/SOL002-SOL003/tree/master/src/SOL003/VNFLifecycleOperationGranting swagger to generate grant services
Grant decisions based on the data either from 1) OOF (based on location, inventory data, resource availability, business rules, etc.) or 2) VIM registration, cloud region, etc.
- In Dublin, the option #2 will be supported first.
- Subscription to SVNFM for getting notifications
- STARTING, PROCESSING, COMPLETED
- Invoking SVNFM based on SOL003 VNF LCM APIs as a client
- SVNFM selection based on configuration values that are configured during VNF on-boarding and VNFM registration. Two methods are considered:
- Correlation between VNF NF Type and VNFM Type (Nokia method)
- Utilizing VNFD vnfm_info:type, VNFM registration values: VNFM type, Cloud region, vendor
...
- Vendor SVNFM must be "SOL003-compliant"
- Providing SOL003 APIs for VNFM LCM, based on ETSI VNFLifecycleManagement
- Use https://forge.etsi.org/gitlab/nfv/SOL002-SOL003/2.5.1/master/src/SOL003/VNFLifecycleManagement swagger for providing services
- Create
- Instantiate
- Grant request to SO VNFM Adapter, as a client
- Life cycle notification
- Terminate
- Registration itself to ONAP (thru A&AI ESR) - Name, Type, Vendor, Version, URL, VIM, Username and Password
- Providing Subscription Services for Life-cycle Management Notifications
- Support of the "Direct Mode" of Resource Management only
- After receiving a grant permission, the VNFM sends requests for resources directly to VIM
- Invoking MultiCloud from VNFM is under discussion, but not for Dublin
- The "Indirect Mode" of Resource Management is being discussed, but not for Dublin
...
- The following diagram depicts the component architecture.
- The VNFM Adapter will be a SO sub-component; packaged as a docker and running in a container.
- VNFM will register into A&AI ESR and VNFM Adapter will locate a proper VNFM based on VNF NF Type or others.
- Communications between the VNFM Adapter and SVNFM will be SOL003 API-based.
- Communications between the SO BPMN Infra VNFM Adapter REST Client and the VNFM Adapter NBI will be SO-specific; i.e., it does not follow ETSI standards at this time.
- SO SDC Controller receives SOL001/SOL004-based CSAR from SDC, and stores the CSAR reference URLs to TOSCA_CSAR database table (see the note below).
- Currently, VNF package output from SDC is not ETSI alignment. If SDC does not support it Dublin, use the standard package under the artifact directory (e.g., Artifact/Deployment/Others)
- In Dublin release, there could be two CSAR file contents: one for the original CSAR and one for ONAP-compliant CSAR (maybe the ONAP-compliant CSAR includes the original package)
- It is assumed that SDC keeps the original vendor VNF packages in their repository, and VNFM Adapter retrieves the original vendor CSAR files from the repository.
- Note: if SDC does not support SOL004 VNF package in Dublin, the SO VNFM Adapter will retrieve the VNFD from SDC directly, bypassing SO TOSCA_CSAR database table.
- New VNF-level workflows that use VNFM Adapter will be implemented, and these new workflows will be invoked from 1) the (Network) Service-level workflows based on VNF type and other criteria or 2) the al carte VNF invocation from VID.
- In Dublin, the second option will be supported.
- Unlike the existing SO VNF/VF-Module workflows, the new ETSI VNF-level/VF-Module-level workflows will NOT interact with OpenStack directly. The workflows will delegate the VNF LCM requests to VNFM Adapter, and VNFM Adapter will delegate the requests to VNFM further. Then, VNFM will interact with VIM directly. In Dublin release, the direct mode of resource management will be supported as depicted above.
...
SOL001/SOL004 Standard Conformance
VNF Package
- A VNF Package is a compressed file that contains the following:
- One VNF descriptor (VNFD)
- One or more Software Image files
- Zero or more manifest files
- Other files
Package structure is SOL004 2.5.1 compliant.
- Note: SDC in Dublin has limitations and restrictions on SOL004 support:
- SDC does not allow custom directories such as Images, Scripts, Licenses and HOT in the root directory.
- SDC requires MainServiceTemplate.mf and MainServiceTemplate.yaml in the root directory
- As a result, in Dublin, the vendor VNF package should follow SDC onboarding rules. These SDC restrictions and limitations plan to be removed in the El Alto release.
- A VNF Package is a compressed file that contains the following:
Cloud Service Archive (CSAR) format
It is a packaging construct defined in SOL004 2.5.1, identified by a .csar suffix on the package file. There In SOL004, there are two package options. The second option is supported.; one with TOSCA-Metadata, one without TOSCA-Metadata directories:
The CSAR file does not contain TOSCA-Metadata directory, the descriptor yaml file is in the root directory of the CSAR.
The CSAR file contains TOSCA-Metadata directory, the TOSCA meta file in this directory contains the location and name of the descriptor file denoted by Entry
-Definitions
- In ONAP, the second option (with TOSCA-Metadata) is supported.
- Note: in SDC El Alto, if the VNF package with certificate and/or signature will be packaged as a zip file. The csar format continues to be used for the package without certificate and/or signature. The zip file without certificate and/or signature will be considered as an HEAT-based package.
VNFD
It is specified by the SOL001 2.5.1.
- Note 1: that the input and get_input function would be used by a TOSCA orchestrator at run time to access the selected input parameter. If the deployment is not done by a TOSCA orchestrator, the inputs and get_input function may not be needed. The VNFD design should follow the vendor SVNFM orchestration capabilities.
- Note 2: in Dublin, SDC will convert SOL001 VNFD to SDC AID DM, but it is not complete. More mapping design discussions are necessary in El Alto.
VNFM Adapter conforms to the SOL001/SOL004 standards of specification and package management and SOL003 lifecycle operations.
VNF States- Note: in Dublin, SDC does not support SOL004 VNF package yet. SO and SO VNFM Adapter design around SOL004 handling is simplified or deferred to the El Alto release.
Design Scope for Dublin
- Use Cases
- VNFM Adapter Design
- SOL001/SOL004 Support & Design
- SO BPMN Infra & VNFM Adapter Run-time Scenario
- SOL003 API Support
- SO VNFM Adapter SOL003 API Support Design
- VNFM Adapter VNF Package Management (Stretch Goal; under investigationNot part of Dublin)
- SDNC Assignment Management
- VNFM Adapter Locating SVNFM
- VNF Life-cycle Granting
- VNFM Adapter Homing Decision for VNF Granting VNF and VF-Module Deduction(TBD)
Epic
| Epic | Feature | Description | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ETSI Alignment - SO SOL003 plugin support to connect to external VNFMs | ETSI Alignment - SO SOL003 plugin support to connect to an external VNFM.
|
...
- Ericsson Internal Test:
- A vendor provides their VNF Package and SVNFM for managing the vendor-specific VNF package.
- For the SO VNFM Adapter NBI and SOL003-SBI interface validation, Ericsson SVNFM is used for the internal testing
- Integration Test:
- For the integration testing, generic/dummy VNF package and VNFM simulator are provided.
- The generic/dummy VNF package is used to test onboarding and extract SOL001 VNFD parameters extraction during for SOL003-based API parameters, such as descriptor_id, flavor, etc.
- VNFM simulator is a vendor-neutral SOL003-compliant VNFM, which supports SOL003 responses and message exchanges.
- Ericsson Internal Test:
...