SO Plug-in Support for VNFM (SO VNFM Adapter)

SO-ETSI-VNFMAdaptor for Dublin Presentation slide deck at ONAP Paris 2019

Associated JIRA tickets

- JIRA ONAPARC-310 ONAPARC-310 - Getting issue details... STATUS (SO Adapter which uses SOL003 to connect to S/G VNFM)

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
- 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

1. SO SDC Controller gets a SOL004 VNF package with an SOL001 VNFD
2. SO SDC Controller stores a VNF CSAR file reference to the SO Catalog DB (e.g., TOSCA_CSAR database table)
3. VNFM Adapter gets a CSAR package URL from the SO TOSCA_CSAR database table
4. VNFM Adapter gets an original CSAR package file from the SDC repository
  1. 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.
  2. There would be two CSAR packages for a service: one original package, one SDC transformed package.
  3. 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

- 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.

Design

- Current method
  - VnfLCM::locateVnfm(GenericVnf vnf)
  - Get a vnfm list from AAI ESR
  - Find a matched Vnfm, where vnfmInfo.getType() == vnf.getNfType
- New method
  - Under development (TBD)

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

- - - Design
      - TBD
  - Instantiate VNF
    - HTTP Method Type: POST
    - VNFM Endpoint: /vnf_instances/{vnfInstanceId}/instantiate
    - Request Payload: InstantiateVNFRequest
    - Response Header: 202 success
    - Response Body: not applicable

- - - Design
      - TBD
  - 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)

- - - Design
      - TBD

- 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

- - VNF Life-cycle Granting

- - - 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

1. 1. 1. 1. VNFM sends a POST request to the Grant resource with a “GrantRequest” in the body
      2. VNFM Adapter with SO returns to VNFM a “202 Accepted” response with an empty body, and a “Location” header indicates a callback URL
      3. VNFM Adapter with SO makes the granting decision
      4. VNFM keeps trying to obtain the grant by sending a GET request to VNFM Adapter until a “200 OK” response with a “grant” data in the body
      5. VNFM Adapter finishes the granting process and returns a “200 OK” response with a “Grant” data in the body

- VNFM Adapter Homing Decision for VNF Granting

- - Note: the following logic concept is inspired by the VFC Homing decision mechanism.
  - Use of OOF is optional. For those models without using HPA, VNFM Adapter will make a grant decision based on VIM registration information.

- 1. VNFM Adapter sends out homing requests to OOF (OSDF) containing resource info
  2. OOF (OSDF) pulls all the related homing constraints from Policy
  3. OOF (HAS) checks AAI database to pull region (flavor) information
  4. OOF (HAS) communicates with Multi-Cloud to check cloud capacity (vims which fulfill the requirements)
  5. OOF (OSDF) returns homing allocation solution to VNFM Adapter

- - OOF collects information as following:
    - Service and Resource Info, from: AAI
    - HPA Flavors/Capabilities/Capacity Info, from: AAI
    - Policy Models (Homing, PCI) from: Policy
    - Infrastructure Metrics Info (capacity), from: MultiCloud
    - Cloud Agnostic Intent Info, from: MultiCloud
    - PCI configuration data (not yet a part of SDC model)

- 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

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

Space shortcuts

Page tree

SO-ETSI-VNFMAdaptor for Dublin Presentation slide deck at ONAP Paris 2019

Associated JIRA tickets

SO-ETSI Alignment Use Cases for Dublin

SO VNFM Adapter Requirements for Dublin

SVNFM Requirements for Dublin

VNFM Adapter Component Architecture

Design Scope for Dublin

Use Cases

SOL001/SOL004 Support & Design

CSAR Import, Store and Retrieve Sequences

Design

VNFM Adapter VNF Package Management

VNF Package Management Interface

Design

VNFM Adapter Design

VNFM Adapter Locating SVNFM

Design

SOL003 Support and Design

SOL003 Interfaces between VNFM Adapter (Client) and SVNFM (Provider)

SOL003 Interfaces between SVNFM (Client) and VNFM Adapter (Provider)

Grant VNF Request

VNF Life-cycle Granting

VNFM Adapter Homing Decision for VNF Granting

More SVFM SOL003 Interfaces for Future Release

Impacted ONAP components

Open Items