...
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/, delete, LCN subscription and LCN
Support of Delete VNF is a stretch goal in Dublin
Enhance SO BPMN workflows & recipes
VNF-level Building Block workflows, leveraging VNFM Adapter
Passing VNF LCM requests to VNFM using VNFM Adapter
- Note: the followings are candidates for the El Alto release.
Provide VNF package management for VNFM
Policy-based VNF scaling thru VNFM Adapter
- Support of remaining SOL003 APIs
- 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
...
Gliffy Diagram | ||||
---|---|---|---|---|
|
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. In SOL004, there are two package options; 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.
...
- Epic and Use Stories
- 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 (Not part of Dublin)
- SDNC Assignment Management
- VNFM Adapter Locating SVNFM
- VNF Life-cycle Granting
- VNFM Adapter Homing Decision for VNF Granting (TBD)
- SVNFM Simulator
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.
|
User Stories
User Stories | Feature | Description | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
| Create the Functional test case to validate VNFM Adapter NBI and SOL003-based SBI | Validate VNFM Adapter NBI and SOL003-based SBI | ||||||||
| SVNFM Simulator | For integration testing in ONAP, vendor-neutral SVNFM is needed, This SVNFM Simulator supports SOL003-based interfaces and message exchange sequences for interface verification.
| ||||||||
| Create SO VNFM Adapter Northbound Interface using Swagger | Create SO VNFM Adapter Northbound Interface using Swagger | ||||||||
| Create Shell Adapter |
| ||||||||
| Create placeholder implementation for create VNF (without SVNFM interaction) |
Note: manual database update to trigger new BB flow and no pre-load | ||||||||
| Check for existing VNF (with SVNFM Interaction) |
| ||||||||
| Handle Create VNF request in VNFM adapter |
| ||||||||
| Instantiate VNF (with SVNFM Interaction) |
| ||||||||
| Handle Grant Request (Without Homing/OOF) | Reply to grant request based on given VIM info in request | ||||||||
| Monitor Job Status | Monitor Job Status
| ||||||||
| Create relationship between esr-vnfm and generic-vnf in AAI | Create relationship between esr-vnfm and generic-vnf in AAI
| ||||||||
| Handle Notification Subscription | Notification Subscription
| ||||||||
| Notification Handling - Instantiate | Notification Handling - Instantiate
| ||||||||
| Monitor Node Status | Monitor Node Status
| ||||||||
| Handling Homing in Flow | Handling Homing in Flow | ||||||||
| Handle VNF delete and termination (without SVNFM integration) | Deleting/Terminating VNF (without SVNFM integration)
| ||||||||
| Terminate VNF (with SVNFM interaction) | Terminate VNF (with SVNFM interaction)
| ||||||||
| Notification Handling - Terminate | Notification Handling - Terminate
| ||||||||
| Remove SDNC pre-load and introduce user_param handling | Remove SDNC pre-load and introduce user_param handling | ||||||||
| Handle Failure case where notification is missed (Query VNF) | Handle Failure case where notification is missed (Query VNF)
| ||||||||
| Spike - investigate OAM IP address handling for generic-vnf | Investigate OAM IP Address handling for generic-vnf |
...
- 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 extract SOL001 VNFD parameters 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.
- vCPE VNF packages would be used for this integration testing.
- Ericsson Internal Test:
VNFM Adapter Sub-components
Gliffy Diagram | ||||
---|---|---|---|---|
|
- SO VNFM Adapter component is a sub component of SO; utilizing docker image and container managed.
- North Bound Interface (NBI)
- RESTful APIs that support createVnf (invokes both createVnf and instantiateVnf), grantVnf, TerminateVnf/DeleteVnf
- Its APIs are SO specific; i.e., not SOL003-based ones; for the NB API details, see the SO VNFM Adapter APIs page.
- Business Logic layer
- It is invoked by the NBI and provides business logic for createVnf, instantiateVnf, terminateVnf/DeleteVnf
- SDNC and A&AI access to collect assignment and VimConnectionInfo
- Accesses SdcPackageProvider for getting SOL004 package(s) and parameters
- SdcPackageProvider
- Supports SOL001/SOL004 package management
- Provides getPackage, getVnfdId, getFlavorId, getVnfNodeProperty
- Provides getPackage(s), getVnfd, getArtifactFile for SVNFM
- Uses SDC Tosca Parser
- GrantManager
- Provides requestGrantForInstantiate REST API for SVNFM
- Invokes OOF for homing decision; HPA support, and/or non-OOF decision
- SOL003Lcn APIs
- Supports VnfIdentifierCreationNotification, VnfIdentifierDeletionNotification, VnfLcmOperationOccurrenceNotification
- SOL003 Communication Layer
- It is a thin REST client layer, which sends SOL003-compliant requests to SVNFMs and receives responses/notifications from SVNFM.
- For Grant, it provides the Grant REST endpoint for SVNFM
- For the SOL003 Southbound API details, see the SO VNFM Adapter APIs page.
- North Bound Interface (NBI)
- SO VNFM Adapter component is a sub component of SO; utilizing docker image and container managed.
...
Gliffy Diagram | ||||
---|---|---|---|---|
|
- SO BPMN Service workflows dispatch new resource-level workflows based on VNF request parameters (e.g., type, others).
- Once a Service workflow chooses a new workflow path for VNFM Adapter, the subsequent requests for the same VNF will follow the new path.
- an association between VNF and VNFM will be made in A&AI.
- SO BPMN VNF-level resource workflows handle:
- Assign VNF to SDNC
- Retrieve the VNF Assignment from SDNC
- Invoke VNFM Adapter Client with required parameters
- VNFM Adapter Client manages:
- Populate parameter structures based on data from SO workflows
- Invoke VNFM Adapter NBI with required parameters
- VNFM Adapter gets GenericVNF from A&AI
- VNFM Adapter locates the corresponding VNF and VNFM registration info form A&AI (ESR). Two methods are suggested
- Current one: based on VNF NF Type and VNFM Type in A&AI
- Could use VNFD vnfm_info:type, VNFM registration values: VNFM type, Cloud Region, vendor - logic is being designed
- VNFM Adapter gets VimConnectionInfo from A&AI
- Queries A&AI based on the cloud region and tenant id
- Builds the VimConnectionInfo based on the type, service-url, user-name, password, cloud-domain, etc.
- VNFM Adapter uses network assignment (e.g., IP Address) from SO (thru SDNC) and builds the extVirtualLinks and other parameters.
- SO BPMN Service workflows dispatch new resource-level workflows based on VNF request parameters (e.g., type, others).
...
- Delete VNF workflow (EtsiVNFDeleteBB.bpmn)
SO BPMN VF-Module Workflow (not for Dublin)
For ETSI-based VNF package, VF-Module level workflows will NOT be used.
SO VNFM Adapter will interface with SVNFM at the VNF level.
...