SO-ETSI-VNFAdaptor for Dublin Presentation slide deck at ONAP Paris 2019
Associated JIRA tickets
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, query, etc.
Enhance SO BPMN workflows & recipes
VNF-level workflows, leveraging VNFM Adapter
Passing VNF LCM requests to VNFM using VNFM Adaptor
Policy based VNF scale out thru VNFM Adapter (Stretch Goal)
VNFM Adapter interfaces for VES event
Policy Framework for scaling decisions
SO workflows for VNF Scale out
VNF-Level Assignment modeling in SDNC and A&AI (open issue)
VNF Application Configuration thru VNFM Adapter and VNFM (open issue)
SO VNFM Adapter Requirements for Dublin
New SO sub-component, following ONAP Microservice Architecture
Generic VNFM Adapter, supporting SOL003-compliant SVNFMs
- Support SOL003 APIs for VNFM LCM
- VNF Package management (Download & Parse VNF Package)
- Get package files from the SDC repository thru SO
- SO Catalog DB enhancement for SOL001/SOL004 is under discussion, for future release
- 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 create a client
support Create, Instantiate, Query operations
collect data for SOL003 API parameters from SDNC, A&AI and OOF
- Granting, based on ETSI VNFLifecycleOperationGranting
use https://forge.etsi.org/gitlab/nfv/SOL002-SOL003/tree/master/src/SOL003/VNFLifecycleOperationGranting swagger to create grant services
Grant decisions based on the data from OOF or VIM registration
- Subscription to SVNFM for getting notifications
- STARTING, PROCESSING, COMPLETED
- VNF Package management (Download & Parse VNF Package)
- 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
SVNFM Requirements for Dublin
- 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
- Query
- Grant request to SO VNFM Adapter, as a client
- 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
- The "Indirect Mode" of Resource Management is being discussed, but not for Dublin
VNFM Adapter Component Architecture
- 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.
Design Scope for Dublin
- Use Cases
- SOL001/SOL004 Support
- SOL003 API Support
- SO VNFM Adapter SOL003 API Support Design
- VNFM Adapter VNF Package Management
- SO BPMN Infra & VNFM Adapter Runtime
- SDNC Assignment Management
- VNFM Adapter Locating SVNFM
- VNF Life-cycle Granting
- VNFM Adapter Homing Decision for VNF Granting
- VNF and VF-Module Deduction
Use Cases
- TBD
SOL001/SOL004 Support & Design
CSAR Import, Store and Retrieve Sequences
- SO SDC Controller gets a SOL004 VNF package with an SOL001 VNFD
- SO SDC Controller stores a VNF CSAR file reference to the SO Catalog DB (e.g., TOSCA_CSAR database table)
- VNFM Adapter gets a CSAR package URL from the SO TOSCA_CSAR database table
- VNFM Adapter gets an original CSAR package file from the SDC repository
- It is assumed that the Adapter retrieves the original vendor provided CSAR package from SDC repository directory before it passes the package to SVNFM, where SVNFM handles the original CSAR. For that, SDC copy the full original package.
- There would be two CSAR packages for a service: one original package, one SDC transformed package.
- VNFM Adapter passes the original CSAR package to SVNFM because the SVNFM is outside of ONAP and is designed to handle the vendor CSAR package.
Note: SO future release could consider SOL001/SOL004 internal representation in its Catalog DB, or using the Run-time Catalog DB
Design
- TBD
VNFM Adapter VNF Package Management
VNF Package Management Interface
- VNFM Adapter supports VNF Package Management Interface
- Accepts the "Get VNF packages" request and returns VnfPkgInfo[]
- Accepts the "Get VNFD" request and returns Vnfd
- Accepts the "Get VNF artifact" request and return Artifact file
- VNFM Adapter supports VNF Package Management Interface
Design
- TBD
VNFM Adapter Design
- SO VNFM Adapter component (a sub component of SO; docker image and container manged)
- North Bound Interface (NBI)
- RESTful APIs that support createVnf, instantiateVnf, queryVnf
- Business Logic layer
- It is invoked by the NBI and provides business logic for createVnf, instantiateVnf, queryVnf
- SDNC and A&AI access to collect assignment and VimConnectionInfo
- Access SdcPackageProvider for getting SOL003 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
- SOL003Lcn APIs
- Support VnfIdentifierCreationNotification, VnfIdentifierDeletionNotification, VnfLcmOperationOccurrenceNotification
VNFM Adapter Locating SVNFM
- VNFM Adapter locates a proper SVNFM based on VNF NF Type/VNFD and VNFM registration
- Two methods are suggested as follows, and one of them will be chosen.
SOL003 Support and Design
SOL003 Interfaces between VNFM Adapter (Client) and SVNFM (Provider)
Create VNF
HTTP Method Type: POST
VNFM Endpoint: /vnf_instances/
Request Payload: CreateVnfRequest
Response Header: 201 success
Response Body: VnfInstance
Instantiate VNF
HTTP Method Type: POST
VNFM Endpoint: /vnf_instances/{vnfInstanceId}/instantiate
Request Payload: InstantiateVNFRequest
Response Header: 202 success
Response Body: not applicable
Query VNF Instances
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)
SOL003 Interfaces between SVNFM (Client) and VNFM Adapter (Provider)
Grant VNF Request
- HTTP Method Type: POST
VNFM Endpoint: /grants
Request Payload: GrantRequest
Response Header: 201 success
Response Body: not applicable
More SVFM SOL003 Interfaces for Future Release
Scale VNF
HTTP Method Type: POST
- VNFM Endpoint: /vnf_instances/{vnfInstanceId}/scale
- Request Payload: ScaleVnfRequest
- Response Header: 202 accepted
- Response Body: not applicable
- Scale to Level Vnf
- HTTP Method Type: POST
- VNFM Endpoint: /vnf_instances/{vnfInstanceId}/scale_to_level
- Request Payload: ScaleVnfToLevelRequest
- Response Header: 202 accepted
- Response Body: not applicable
Terminate VNF
HTTP Method Type: POST
VNFM Endpoint: /vnf_instances/{vnfInstanceId}/terminate
Request Payload: TerminateVnfRequest
Response Header: 202 success
Response Body: not applicable
- Delete VNF
HTTP Method Type: DELETE
VNFM Endpoint: /vnf_instances/{vnfInstanceId}
Request Payload: not applicable
Response Header: 204 success
Response Body: not applicable
- Operate VNF
HTTP Method Type: POST
VNFM Endpoint: /vnf_instances/{vnfInstanceId}/operate
Request Payload: OperateVnfRequest
Response Header: 202 success
Response Body: not applicable
Impacted ONAP components
- SO
- SO Catalog DB for SOL001/SOL004 support
- BPMN Workflows and Recipes
- VNFM Adapter
- SDC
- Support SOL001/SOL004
- SDNC
- VNF-level Network Assignment, instead of VF-Module
- A&AI
- VNF-level Inventory Update
- VNFM location
- Policy
- Scale-Out support for ETSI-based scaling
- Modeling
- Support SOL001/SOL004
- SO
Open Items
VNF Application Configuration thru VNFM Adapter and VNFM is under discussion
Architecture subcommittee is defining orchestration scenarios for application configuration
Better mechanism for VNFM Adaptor 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
Assigning Network resources to SDNC; do we use preload data?
VNFM Adaptor support of VNFD package management (uploading and downloading) for VNFM
Continue to support existing non-ETSI SO workflows along with ETSI-based workflows
VNFM Adaptor architectural direction; should it work as a thin layer or should it be evolved as a full-fledge NFVO in the future, e.g., handling grant by itself, updating resources in A&AI and SDNC?
After the VNF Instantiation, which component does update VNF resources in A&AI? VNFM Adapter or SO?
SOL001/SOL004 SO Representation
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)
Store minimum reference in TOSCA_CSAR database table?
SOL001 Package management
SO VNFM Adapter supports VNF Package (VnfPkgInfo, VNFD, Artifact) for VNFM
SDNC Preload VNF Topology
MultiCloud use