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
- x
VNFM Adapter VNF Package Management
- 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 Artifactfile
- VNFM Adapter supports VNF Package Management Interface
SO VNFM Adapter SOL003 API Support 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 - SVNFM SOL003 Interfaces
Create VNF
-HTTP Method Type: POST
-VNFM Endpoint: /vnf_instances/
-Request Payload: CreateVnfRequest
-Response Header: 201 success
-Response Body: VnfInstanceInstantiate VNF
-HTTP Method Type: POST
-VNFM Endpoint: /vnf_instances/{vnfInstanceId}/instantiate
-Request Payload: InstantiateVNFRequest
-Response Header: 202 success
-Response Body: not applicableGrant VNF Request
-HTTP Method Type: POST
-VNFM Endpoint: /grants
-Request Payload: GrantRequest
-Response Header: 201 success
-Response Body: not applicableScale VNF
HTTP Method Type: POST
VNFM Endpoint: /vnf_instances/{vnfInstanceId}/scale
Request Payload: ScaleRequest
Response Header: 202 accepted
Response Body: not applicable
- Dublin Requirements
- Build SO VNFM Adapter
- Use SOL003 APIs for VNFM communication
- Support operations such as create, instantiate, scale, etc.
- Support SOL001 VNFD and SOL004 Package
- Enhance SO BPMN workflows & recipes
- Pass VNF LCM requests to VNFM using Adapter
- Modeling and A&AI Updates maybe required
- Some of this work may already be implemented
- Build SO VNFM Adapter
- SO VNFM Adapter Requirements for Dublin
- New SO subcomponent, following ONAP Microservice Architecture
- Generic VNFM Adapter, supporting SOL003-compliant SVNFMs
- Support SOL003 APIs
- Design
- ...
- 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 vs. VF-Modules Modeling