Ericsson: Byung-Woo Jun
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
Enhance SO BPMN workflows & recipes
VNF-level Building Block workflows, leveraging VNFM Adapter
Passing VNF LCM requests to VNFM using VNFM Adapter
Provide VNF package management for VNFM
Policy-based VNF scaling thru VNFM Adapter
A new SO sub-component, following ONAP Microservice Architecture
A Generic VNFM Adapter, supporting SOL003-compliant SVNFMs
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/Delete 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)
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.
Package structure is SOL004 2.5.1 compliant.
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
It is specified by the SOL001 2.5.1.
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 | 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 |
VNFM Adapter depends on the following SDC capabilities:
Note 2: the step 1 is not important for SO VNFM Adapter in Dublin since the Adapter will get VNFD from SDC directly.
Note: SO future release could consider SOL001/SOL004 internal representation in its Catalog DB, or using the Run-time Catalog DB
New VNF-level Building Block workflows will be created.
For ETSI-based VNF package, VF-Module level workflows will NOT be used.
SO VNFM Adapter will interface with SVNFM at the VNF level.
{
"additionalParams ":"{\"param_1\": \"value_1\",\"param_2\": \"value_2\",\"param_3\": \"value_3\"}",
"extVirtualLinks":"[{\"id\": \"vlaue\",\"resourceId\": \"value\",\"extCps\": [{\"cpdId\": \"cpdId_value\",\"fixedAddresses\": [{\"fixedAddresses\": {\"macAddress\": [\"macAddress_1\", \"macAddress_2\"]}}]}]}]"
}
SVNFM is provided by its vendor, which is vendor-specific by nature. For ONAP integration testing for SO VNFM Adapter, a generic VNFM Simulator is needed. This generic VNFM Simulator will support SOL003-compliant interfaces.
In Dublin, the Simulator will support Crate, Instantiate, Terminate and Delete VNF operations and Grant request/response handling. Simulated mock-up request and response data will be exchanged.
HTTP Method Type: POST
VNFM Endpoint: /vnf_instances/
Request Payload: CreateVnfRequest
Response Header: 201 success
Response Body: VnfInstance
VNFM Adapter sends a POST request to the "VNF Instances" resource including in the payload body a data structure of type "CreateVnfRequest" (VNFM Adapter → VNFM); POST ../vnf_instances (CreateVnfRequest)
VNFM creates a new VNF instance resource in NOT_INSTANTIATED state, and the associated VNF instance identifier (VNFM → VNFM Adapter);
VNFM returns a 201 Created response containing a representation of the VNF Instance resource just created by the VNFM, and provides the URI of the newly-created resource in the "Location" HTTP header (VNFM → VNFM Adapter); 202 Created (VnfInstnace)
Parameters | Required? | Data Source | Note |
---|---|---|---|
vnfdId | Required | descriptor_id from VNFD | |
vnfInstanceName | Optional | User Input | |
vnfInstanceDescription | Optional | User Input |
HTTP Method Type: POST
VNFM Endpoint: /vnf_instances/{vnfInstanceId}/instantiate
Request Payload: InstantiateVNFRequest
Response Header: 202 success
Response Body: not applicable
Parameters and data source
Parameter | Required? | Data Source | Note |
---|---|---|---|
flavorId | Optional | From user input or from the VNFD | This parameter is optional for NBI but it is mandatory for southbound. The value from the user; otherwise it takes the default value from VNFD |
instantiationLevelId | Optional | From VNFD | |
extVirtualLinks | Optional | From preload data or user input | The user input requires UI enhancement - See below for design proposal If the external connection point ip_address_assignment is set to false, extVirtualLink is not necessary since the ip address is set by VIM dynamically. |
extManagedVirtualLinks | Optional | from user input | Externally-managed internal VL; Not supported in Dublin |
vimConnectionInfo | Optional | From AAI | In Dublin, the direct resource mode is supported, that means all the VIM resources are created directly by VNFM |
localizationLanguage | Optional | Not supported in Dublin | |
additonalParams | Optional | From VNFD | It is a mechanism to pass vendor-specific parameters |
Trace which VNFM instance managed which VNF instance, the following rule will be added to A&AI DB Edge (DbEdgeRules_esr_v15.json, DbEdgeRules_esr_v16.json).
{
"from": "generic-vnf",
"to": "esr-vnfm",
"label": "tosca.relationships.DependsOn",
"direction": "OUT",
"multiplicity": "MANY2ONE",
"contains-other-v": "NONE",
"delete-other-v": "NONE",
"prevent-delete": "NONE",
"default": "true",
"description":""
}
SO VNFM Adapter will update the relationship between generic-vnf and esr-vnfm based on the rule.
HTTP Method Type: GET
VNFM Endpoint: /vnf_instances (for multiple VNFs), /vnf_instances/{vnfInstanceId} (for single VNF)
Request Payload: not applicable
Response Header: 200 success
Response Body: VnfInstance[] (for multiple VNFs), VnfInstance (for single VNF)
VNFM Endpoint: /grants
Request Payload: GrantRequest
Response Header: 201 success
Response Body: not applicable
The purpose of the grant request is to have the VNFM’s resource request authorized by VNFM Adapter/SO and to get advice on where to allocate resources such as virtual machines based upon capacity.
Grant requests are also useful to ensure that all resources (capacity, quota, flavors, SRTs, etc.) required for successful VNF deployment are available.
There are two Grant Response modes, synchronous and asynchronous. Synchronous response mode will be supported for Dublin.
Synchronous Mode
VNFM sends a POST request to the Grant resource with a “GrantRequest” in the body
VNFM Adapter with SO makes the granting decision
VNFM Adapter with SO returns to VNFM a “201 Created” response with a “Grant” data structure in the body
Asynchronous Mode
HTTP Method Type: POST
VNFM Endpoint: /vnf_instances/{vnfInstanceId}/terminate
Request Payload: TerminateVnfRequest
Response Header: 202 success
Response Body: not applicable
Parameters and Data source
Parameter | Required? | Data Source | Note |
---|---|---|---|
terminationType | Yes | from user input | |
gracefulTerminationTimeout | Optional | from user input | This attribute is only applicable in case of graceful termination. The unit is seconds |
additionalParams | Option | from VNFD |
HTTP Method Type: DELETE
VNFM Endpoint: /vnf_instances/{vnfInstanceId}
Request Payload: not applicable
Response Header: 204 success
Response Body: not applicable
After the operation, VNF resource has been removed from the list of VNF instance resources
Scale VNF
HTTP Method Type: POST
HTTP Method Type: DELETE
VNFM Endpoint: /vnf_instances/{vnfInstanceId}
Request Payload: not applicable
Response Header: 204 success
Response Body: not applicable
HTTP Method Type: POST
VNFM Endpoint: /vnf_instances/{vnfInstanceId}/operate
Request Payload: OperateVnfRequest
Response Header: 202 success
Response Body: not applicable
VNF Application Configuration thru VNFM Adapter and VNFM is under discussion (out of scope from Dublin)
Architecture subcommittee is defining orchestration scenarios for application configuration
Better mechanism for VNFM Adapter to locate VNFMs (two methods are suggested)
How do we identify which VNFM to use?
Modelling for VNF and VF Modules; mapping between VF Modules and VNF (out of scope from Dublin)
Assigning Network resources to SDNC; do we use preload data?
Continue to support existing non-ETSI SO workflows along with ETSI-based workflows
SOL001/SOL004 SO Representation (for Dublin, the second option was chosen)
Option #1: Enhance SO Catalog Database?
VNF_Package (vnfdid, vnfm_info, version, vnf_provider, product, vendor, etc.)
VNF_Package_Artifact (child database for VNF_Package, VNFD_URL, SoftwareImage_URL, Additional Files etc)
Option #2: Store minimum reference in TOSCA_CSAR database table? This was chosen for Dublin
MultiCloud use (not for Dublin)
SO VNFM Adapter High Availability and error handling are not fully covered.