Content Comparison

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

...

- 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
  - Life cycle notification
- 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, but not for Dublin
  - The "Indirect Mode" of Resource Management is being discussed, but not for Dublin

...

- 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.
- VNFM will register into A&AI ESR and VNFM Adapter will locate a proper VNFM based on VNF NF Type or others.
- Communications between the VNFM Adapter and SVNFM will be SOL003 API-based.
- Communications between the SO BPMN Infra VNFM Adapter REST Client and the VNFM Adapter NBI will be SO-specific; i.e., it does not follow ETSI standards at this time.
- SO SDC Controller receives SOL001/SOL004-based CSAR from SDC, and stores the CSAR reference URLs to TOSCA_CSAR database table.
  - Currently, VNF package output from SDC is not ETSI alignment. If SDC does not support it Dublin, use the standard package under the artifact directory (e.g., Artifact/Deployment/Others)
  - In Dublin release, there could be two CSAR file contents: one for the original CSAR and one for ONAP-compliant CSAR (maybe the ONAP-compliant CSAR includes the original package)
  - It is assumed that SDC keeps the original vendor VNF packages in their repository, and VNFM Adapter retrieves the original vendor CSAR files from the repository.
- New VNF-level workflows that use VNFM Adapter will be implemented, and these new workflows will be invoked from the (Network) Service-level workflows based on VNF type and other criteria.
- Unlike the existing SO VNF/VF-Module workflows, the new VNF-level/VF-Module-level workflows will NOT interact with OpenStack directly. The workflows will delegate the VNF LCM requests to VNFM Adapter, and VNFM Adapter will delegate the requests to VNFM further. Then, VNFM will interact with VIM directly. In Dublin release, the direct mode of resource management will be supported as depicted above.

...

Use Cases
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 (Stretch Goal; under investigation)
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

- Choose a use case for demonstrating the VNFM Adapter capabilities
- Under investigation (will determine soon)

VNFM Adapter Sub-components
Image Removed
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, grantVnf
- Its APIs are SO specific; i.e., not SOL003-based ones

Business Logic layerIt is invoked by the NBI and

Standards

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.
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. There are two package options. The second option is supported.
- 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

VNFD
- It is specified by the SOL001 2.5.1

VNFM Adapter conforms to the SOL001/SOL004 standards of specification and package management and SOL003 lifecycle operations.

Design Scope for Dublin

- Use Cases
- 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 (Stretch Goal; under investigation)
- SDNC Assignment Management
- VNFM Adapter Locating SVNFM
- VNF Life-cycle Granting
- VNFM Adapter Homing Decision for VNF Granting
- VNF and VF-Module Deduction

EPICs

EPIC	Feature	Description
1	Create VNF	Create a VNF Id
2	Instantiate VNF	Instantiate a VNF
3	Query VNF	Query VNF Info

Use Cases

- Choose a use case for demonstrating the VNFM Adapter capabilities
- Under investigation (will determine soon)

VNFM Adapter Sub-components

Image Added
- - SO VNFM Adapter component is a sub component of SO; utilizing docker image and container manged.
  - North Bound Interface (NBI)
    - RESTful APIs that support createVnf, instantiateVnf, queryVnf, grantVnf
    - Its APIs are SO specific; i.e., not SOL003-based ones
  - 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
    - Accesses 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, 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 SVNFMs.
SOL001/SOL004 Support & Design
- - - - 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 SVNFMs.

SOL001/SOL004 Support & Design

- SDC VNF SOL001/SOL004 Support
  - VNFM Adapter depends on the following SDC capabilities:
    - SOL004-based VNF CSAR package onboarding, including storing the original VNF package in SDC output.
    - Manual onboarding of VNF package thru SDC UI.
    - Mapping VNFD (SOL001) to SDC AID DM, including VF-Module deduction based on ScaleAspect + Delta
    - SDC TOSCA Parser for SDC/ONAP Internal model
    - TOSCA Parser for SOL001
    - VNF SDK support of VNF package verification
  - SDC support for VNF SOL001/SOL004 is under discussion (Ericsson, Nokia contribution)

CSAR Import, Store and Retrieve Sequences
- SDC stores the original vendor VNF package along the ONAP-compliant package.

1. SO SDC Controller gets a SOL004 VNF package with an SOL001 VNFD
  1. SDC could generate two output: one ONAP-compliant CSAR and one original CSAR (maybe the first file includes the second one)
  2. SO will use the ONAP-compliant CSAR
  3. VNFM Adapter will use original CSAR
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

- <add pseudo code here>TBD

VNFM Adapter Run-time Scenarios

...

VNFM Adapter VNF Package Management (Stretch Goal; under investigation)

- VNF Package Management
  Interface
  Execution Flow

- - VNFM Adapter supports VNF Package Management Interface
    - Accepts the "Get VNF packages" request and returns "200 OK" with VnfPkgInfo[]
    - Accepts the "Get VNFD" request and returns "200 OK" with Vnfd
    - Accepts the "Get VNF artifact" request and return returns "200 OK" with Artifact file

- Design

- - Getting multiple VNF packages

...

- - - Design
      - 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)
      - VNFM sends a VNF Identifier Creation Notification to the VNFM Adapter to indicate the creation of the VNF instance resource and the associated VNF instance identifier (VNFM → VNFM Adapter); Send VnfIdentifierCreationNotificationVnfIdentifierCreationNotification
      - Parameters and data source

Parameters	Data Source
vnfdId	descriptor_id from VNFD
vinfInstanceName	User Input
vnfInstanceDescription	User Input

- - Instantiate VNF
    - HTTP Method Type: POST
    - VNFM Endpoint: /vnf_instances/{vnfInstanceId}/instantiate
    - Request Payload: InstantiateVNFRequest
    - Response Header: 202 success
    - Response Body: not applicable
  - VNFM Adapter sends a POST request to the Task resource that represents the lifecycle operation to be executed on the VNF instance, and includes in the payload body a data structure of type InstantiateVNFRequest (VNFM Adapter → VNFM); POST ../vnf_instances/{vnfInstanceId}/instantiate
  - VNFM Creates a "VNF LCM operation occurrence" resource for the request (VNFM → VNFM Adapter)
  - VNFM returns a "202 Accepted" response with an empty payload body and a "Location" HTTP header that points to the new "VNF LCM operation occurrence" resource (VNFM → VNFM Adapter); .../vnf_lcm_op_occs/{vnfLcmOpOccId}

Design

VNFM Adapter sends a POST request to the Task resource that represents the lifecycle operation to be executed on the VNF instance, and includes in the payload body a data structure of type InstantiateVNFRequest (VNFM Adapter → VNFM); POST ../vnf_instances/{vnfInstanceId}/instantiate
VNFM Creates a "VNF LCM operation occurrence" resource for the request (VNFM → VNFM Adapter)
VNFM returns a "202 Accepted" response with an empty payload body and a "Location" HTTP header that points to the new "VNF LCM operation occurrence" resource (VNFM → VNFM Adapter); .../vnf_lcm_op_occs/{vnfLcmOpOccId}
VNFM sends to the VNFM Adapter a VNF lifecycle management operation occurrence notification to indicate the start of the lifecycle management operation occurrence with the "STARTING" state
VNFM and VNFM Adapter exchange granting information (see Granting section)
VNFM sends to the VNFM Adapter a VNF lifecycle management operation occurrence notification to indicate that the VNF LCM operation occurrence enters the "PROCESSING" state
VNFM Adapter polls the "VNF LCM operation occurrence" resource to obtain information about the ongoing operation by sending a GET request to the resource that represents the VNF LCM operation occurrence.
VNFM returns to the VNFM Adapter information of the operation, such as the operation status, by providing in the payload body a data structure of type "VnfLcmOpOcc"
VNFM has finished the operation <<Operation>>
VNFM sends a VNF lifecycle management operation occurrence notification to VNFM Adapter to indicate the start completion of the lifecycle management operation occurrence with the success state "STARTINGCOMPLETED" state
VNFM and VNFM Adapter exchange granting information (see Granting section)
VNFM sends to the NFVO a VNF lifecycle management operation occurrence notification to indicate that the VNF LCM operation occurrence enters the "PROCESSING" state
VNFM Adapter polls the "VNF LCM operation occurrence" resource to obtain information about the ongoing operation by sending a GET request to the resource that represents the VNF LCM operation occurrence.
VNFM returns to the VNFM Adapter information of the operation, such as the operation status, by providing in the payload body a data structure of type "VnfLcmOpOcc"
VNFM has finished the operation <<Operation>>

VNFM sends a VNF lifecycle management operation occurrence notification to VNFM Adapter to indicate the completion of the lifecycle management operation occurrence with the success state "COMPLETED"

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

- - - - Open Issues:
        How to and from where fill up ExternalVirtualLinks: IP Address, and OAM IPAddress? Use of Additional Parameters to pass IP Addresses that are extracted from HEAT templates?

- - 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
      - If the VNFM Adapter intends to query all VNF instances, it sends a GET request to the "VNF instances" resource
      - The VNFM returns a "200 OK" response to the VNFM Adapter, and includes zero or more data structures of type "VnfInstance" in the payload body
      - If the VNFM Adapter intends to read information about a particular VNF instance, it sends a GET request to the "Individual VNF instance" resource, addressed by the appropriate VNF instance identifier in its resource URI
      - The VNFM returns a "200 OK" response to the VNFM Adapter, and includes one data structure of type "VnfInstance" in the payload body

- - 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
        VNFM Adapter with SO returns to VNFM a “202 Accepted” response with an empty body, and a “Location” header indicates a callback URL
        VNFM Adapter with SO makes the granting decision
        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
        VNFM Adapter finishes the granting process and returns a “200 OK” response with a “Grant” data in the body

Image Modified

- - - VNFM Adapter Homing Decision for VNF Granting

- - - - Note: the following logic concept is inspired by the VFC Homing decision mechanism (location, inventory data, resource availability, business rules, etc.)
      - Use of OOF is optional. For those models without using HPA, VNFM Adapter will make a grant decision based on VIM registration information.

Image Modified

1. 1. 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 (Stretch goal for Dublin)
      - 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
    - VF Module deduction based on SOL001
  - SDNC
    - VNF-level Network Assignment, instead of VF-Module
  - A&AI
    - VNF-level Inventory Update
    - VNFM location
  - Policy (Stretch goal) - not for Dublin
    - Scale-Out support for ETSI-based scaling
  - Modeling
    - Support SOL001/SOL004
    - ETSI vs. ONAP-compliant VNFD

- Open Items

- - SDC transformation between ETSI and ONAP internal output and storing the original CSAR package.
  - VNF Application Configuration thru VNFM Adapter and VNFM is under discussion
    - 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
    - Assigning Network resources to SDNC; do we use preload data?
  - Continue to support existing non-ETSI SO workflows along with ETSI-based workflows
  - VNFM Adapter architectural direction; should it work as a thin layer or should it be evolved as a full-fledged 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 (for Dublin, the second option was chosen)
    - 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? This was chosen for Dublin
  - MultiCloud use (not for Dublin)

Version	Old Version 51	New Version 52
Changes made by	Byung-Woo Jun	Byung-Woo Jun
Saved on	Jan 31, 2019	Feb 07, 2019

Versions Compared

Key

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

SOL001/SOL004

Use Cases

VNFM Adapter Sub-components

Standards

VNF Package

Cloud Service Archive (CSAR) format

VNFD

VNFM Adapter conforms to the SOL001/SOL004 standards of specification and package management and SOL003 lifecycle operations.

Design Scope for Dublin

EPICs

Use Cases

VNFM Adapter Sub-components

SOL001/SOL004 Support & Design

SDC VNF SOL001/SOL004 Support

CSAR Import, Store and Retrieve Sequences

Design

VNFM Adapter Run-time Scenarios

VNFM Adapter VNF Package Management (Stretch Goal; under investigation)

VNF Package Management

Execution Flow

Design

Getting multiple VNF packages

Design

Instantiate VNF

Query VNF Instances

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