SOL003 Adapter

Use Case

To manage vendor-provided VNFs and VIMs, ONAP wants to leverage the vendor-supplied VNFMs. For that, ONAP SO in Dublin added a plug-in capability for SVNFMs and interfaces with the plugged SVNFMs through SOL003 API standards, along with SOL004 VNF packages which include SOL001 VNFD. The SOL003 Adapter in Dublin supported the SOL003 Create, Instantiate, Terminate and Delete operations with Granting, Subscription and Notification. In the Frankfurt release, the additional SOL003 operations will be supported as follows. For the SOL004 and SOL001 support, see the ETSI Package Management section (ETSI Package Management).

• Package Management for SVNFM
• Granting Enhancement with HPA
• Query
• Modify (TBD)
• Policy-based Scaling (Stretch goal)
• Security between the Adapter and VNFMs
• Additional operations will be determined

Feature Descriptions

Epic and User Story

SOL003 VNFM Adapter Architecture for Frankfurt

The diagram depicts SOL003 VNFM Adapter Architecture.

1. VNFM Adapter exposes its NBI to any VNFM Adapter client
   1. VNFM Adapter continues to be a SO microservice component.
   2. VNFM Adapter will be registered to MSB.
   3. a VNFM Adapter client (e.g., GNFC) will locate the VNFM Adapter through MSB.
2. Interfaces are refactored to be generic (accessed by other ONAP/External components) - TBD
   1. the VNFM Adapter NBI will be enhanced for additional SOL003 operation support.
3. SDC CSAR including the SDC internal model and the vendor original SOL004 package is supported
4. SO leverages ONAP-ETSI Catalog microservice for ETSI-based NS, VNF and PNF
5. VNFM Adapter retrieves VNF package from Catalog Manager
6. VNFM Adapter Client uses MSB to locate the VNFM Adapter
7. VNFM Adapter locates a VNFM based on a better VNFM locating mechanism
8. VNFM Adapter and SVNFM support additional SOL003 operations, possibly including modification for configuration
9. VNFM Adapter and SVNFM support authentication and authorization
   1. AAF will be used for authentication and authorization
   2. But, vendor SVNFMs may use their own AA mechanism
10. VNFM Adapter interfaces with OOF to support HPA-support granting (see the Granting enhancement section)
11. For the integration testing, the VNFM Simulator in the CSIT container will be used.

SOL003 Operations

The following SOL003 operations will be supported:

• Package Management
• Grant enhancement
• Query of VNF
• Scaling (stretch goal)
• Modify
• Operation Status

SOL003-based Operation Sequence Flows

• Create / Instantiate VNF
  • It is supported in the Dublin release, and it will be enhanced to leverage the ONAP-ETSI Catalog Manager.
• The following sequence flows depicts the SOL003 Create/Instantiate operations by leveraging the above architecture. 

• Terminate/Delete VNF
  • It is supported in the Dublin release, and it will be enhanced to leverage the ONAP-ETSI Catalog Manager.
• The following sequence flows depicts the SOL003 Terminate/Delete operations by leveraging the above architecture. 

<Diagram : tbd>

SOL003 Adapter - SVNFM - ETSI Catalog Manager Operations

The SOL003 Adapter supports the following SOL003-based operations.

Operation Interfaces Requirements

/vnf_packages, /vnf_packages/{vnfPkgId}

/vnf_packages/{vnfPkgId}/vnfd

/vnf_packages/{vnfPkgId}/package_content

/vnf_packages/{vnfPkgId}/artifacts/{artifactPath}

Package Management

• Query/Reading VNF package information (VNFM → SOL003 Adapter)

  • SOL003 Adapter Package - Query VNF Package

    • SOL003 Adapter provides the SOL003 Query/Reading VNF package services to the SVNFM.
    • SVNFM requests for multiple VNF packages or an individual VNF package for the given vnfPkgId.
      • /vnf_packages, /vnf_packages/{vnfPkgId}
    • SOL003 Adapter queries for VNF packages or an individual VNF package to the ETSI Catalog Manager.
    • ETSI Catalog Manager returns VNF packages or an individual VNF package to the SOL003 Adapter
    • SOL003 Adapter returns the VnfPkgInfo[] or VnfPkgInfo to the SVNFM

    Precondition: one or more individual VNF package resources are created.

    Postcondition: SVNFM receives VNF packages or an individual VNF package in form of VnfPkgInfo[] or VnfPkgInfo

• Reading VNFD of an on-boarded VNF package (VNFM → SOL003 Adapter)

  • SOL003 Adapter Package Management - Read VNFD

    • SOL003 Adapter provides the SOL003 Reading VNFD service to SVNFM.
    • SVNFM requests for a VNFD for the given vnfd
    • SOL003 Adapter requests for a VNFD for the given vnfd to ETSI Catalog Manager
    • ETSI Catalog Manager returns a VNF package including vnfdModel JSON
    • SOL003 Adapter returns a Vnfd with the vnfdModel JSON to SVNFM

    
    

    Precondition: The VNF package is onboarded to the ONAP-ETSI Catalog Manager

    Postcondition: SVNFM receives Vnfd

• Fetching an on-boarded VNF package (VNFM → SOL003 Adapter)
  • SOL003 Adapter supports the whole package content fetch only.
  • SVNFM sends a GET request for the VNF package content resource to the SOL003 Adapter.
    • GET .../vnf_packages/{vnfPkgId}/package_content
  • SOL003 Adapter sends a GET request for the VNF package content resource to the ETSI Catalog Manager
    • GET .../vnf_pacakges/{vnfPkgId}/package_content or 
    • ETSI Catalog Manager API: GET /api/vnfpkgm/v1/vnf_packages/{vnfPkgId}/package_content  (To be enhanced to make it as the SOL003 standard interface)
  • ETSI Catalog Manager returns a copy of the VNF package file in the payload body to SOL003 Adapter.
  • SOL003 Adapter returns with a copy of the VNF package file in the payload body to SVNFM.

Precondition: the VNF package is onboarded to the ETSI Catalog Manager

Postcondition: the SVNFM gets the whole content of the VNF package

• Fetching a VNF package artifact (VNFM → SOL003 Adapter)
  • The SOL003 Adapter supports the whole content of the artifact only.
  • The SVNFM sends a GET request for the Individual VNF package artifact to SOL003 Adapter.
    • GET .../vnf_packages/{vnfPkgId}/artifacts/{artifactPath}
  • The SOL003 Adapter sends a GET request for the individual VNF package artifact to the ETSI Catalog Manager
    • GET .../vnf_packages/{vnfPkgId}/artifacts/{artifactPath} or
    • ETSI Catalog Manager API  .../api/vnfpkgm/v1/vnf_packages/{vnfPkgId}/artifacts/{artifactPath} // to be enhanced.
  • The ETSI Catalog Manager returns a copy of the applicable artifact files from the onboarded VNF package to the SOL003 Adapter.
  • The SOL003 Adapter returns with a copy of the applicable artifact file from the onboarded VNF package to SVNFM.

Precondition: The VNF package is onboarded to the ONAP-ETSI Catalog Manager

Postcondition: the SVNF gets the applicable artifact file.

• Creating subscriptions for the package management (VNFM → SOL003 Adapter)
  • Subscribe (SVNFM → SOL003 Adapter) : subscribe to notifications related to onboarding and/or changes of VNF package
  • The SVNFM sends a POST request for the Subscriptions resource including PkgSubscriptionRequest to the SOL003 Adapter.
  • The SOL003 Adapter returns with a data structure of PkgmSubscription to the SVNFM

Precondition: SVNFM does not have package subscription.

Postcondition: SOL003 Adapter create subscription resource in memory (persistency is to be determined) 

                           SVNFM gets package subscription (PkgmSubscription)

• Query Subscription Info
  • SVNFM re-synchronizes all or selected subscriptions after some errors in SVNFM or some exception handling.
  • SVNFM sends a Query Subscription Info request to the SOL003 Adapter.
    • GET .../subscriptions  // for all subscriptions
  • SOL003 Adapter returns package subscription lists in the form of PkgmSubscription[] in the payload
  • or
  • SVNFM sends a Query Subscription Info request for a selected subscription to the SOL003 Adapter 
    • GET .../subscriptions/{subscriptionId}
  • SOL003 Adapter returns a selected package subscription to SVNFM.

Precondition: SVNFM lost package subscription information

Postcondition: SVNFM gets package subscription information

• Delete Subscription
  • SVNFM does not need the subscription anymore.
  • SVNFM sends a request for Terminate/Delete Subscription to the SOL003 Adapter. 
  • SOL003 Adapter removes the SVNFM package subscription.
  • SOL003 Adapter sends the 204 No content response to SVNFM.

Precondition: SVNFM subscribed to the SOL003 Adapter for package notifications

Postcondition: SOL003 Adapter removed the SVNFM package subscription.

• Sending notifications for the package management (SOL003 Adapter → VNFM)
  • If an event occurs that matches the filtering criteria, the SOL003 Adapter generates a notification that includes information about the event, and sends it to the registered SVNFM.
  • SOL003 Adapter receives a notification from the ONAP-ETSI Catalog Manager
  • SOL003 Adapter sends a Notify message about VNF package onboarding or change
    • POST <<Client side URL>> (<<Notification>>)
  • SVNFM acknowledges the successful delivery of notification.
    • 204 No content

Precondition: SVNFM has subscribed to the SOL003 Adapter previously

                        SOL003 Adapter subscribed to the ETSI Catalog Manager previously

Postcondition: SVNFM receives a notification

Grant Request with Synchronous Response with HPA (VNFM → SOL003 Adapter)

The SOL003 Adapter acts as a NFVO and supports the Synchronous Grant operation. Hardware Platform capability requirements are downloaded as part of the VNFD data.

There are two methods to support HPA in SO:

• Method 1: Use of Homing information that is made during the SO decompose processing.
  • During SO decompose processing, SO calls OOF for collecting homing information for the service (which includes the VNFs).
  • Call the OOF APIs to perform the optimize service/VNF homing and placement
  • Use the existing homing workflows to pass hardware platform capability requirements to OOF
  • See the following diagram for the component interaction.

Postcondition: SVNFM receives a granting

• Method 2: If the above processing does not work for the vendor VNF HPA, OOF will be called from the SOL003 Adapter per VNF. The following describes the interactions between SOL003 Adapter and OOF.
  • Note: current, OOF does NOT support the VNF Level Homing request. OOF API enhancement is under discussion. Otherwise, the method 1 (Service Level Homing) is used for Frankfurt. TBD.
  • VNFM Adapter sends out homing requests to OOF (OSDF) containing resource info
  • OOF (OSDF) pulls all the related homing constraints from Policy
  • OOF (HAS) checks AAI database to pull region (flavor) information
  • OOF (HAS) communicates with Multi-Cloud to check cloud capacity (vims which fulfill the requirements)
  • 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)
• SOL003 Adapter Homing Request to OOF
  • <describe the homing request API and contract here>

GrantRequest Structure

Grant Structure

Specifying HPA Capability Requirements using SOL001 VNFD

The VNFD is used to describe VNF-specific HPA capability requirements that will be matched against the capabilities of the underlying hardware infrastructure resources.

For HPA requirements, see Specifying HPA Capability Requirements using TOSCA-based VNF Descriptors. 

<TBD>

ONAP Component Interactions for HPA

source: Policy and Information sources for HAS

Homing policies may come from vendor, service architect and ONAP Operator/Administrator.

<describe further>

Query VNF (SOL003 Adapter → VNFM)

• SOL003 Adapter sends a query request for VNF instance(s) - multiple or selected VNF instance
  • GET .../vnf_instances                                         // multiple VNF instances
  • GET .../vnf_instances/{VnfInstnaceId}            // selected VNF instance
• SVNFM returns VNF Instance(s) in form of VnfInstance[] or VnfInstance
  • 200 OK with VnfInstance[]
  • 200 OK with VnfInstance

Precondition: VNF instance is created

Postcondition: SOL003 Adapter gets VnfInstance[] or VnfInstance

Modify VNF (SOL003 Adapter → VNFM)

The SOL003 Adapter requests the Modify VNF to the VNFM.

Note: it is out of Frankfurt scope.

Get Operation Status (SOL003 Adapter → VNFM)

The SOL003 Adapter requests the Get Operation Status operation. The following diagram depicts a sequence for obtaining the status of a VNF lifecycle management operation occurrence.

SOL003 Adapter supports VNF Operation Status

• SOL003 Adapter sends a request for VNF LCM operation occurrence(s) to the SVNFM
  • GET .../vnf_lcm_op_occs                                       // multiple
  • GET .../vnf_lcm_op_occs/{vnfLcmOpOccId}      // single
• VNFM returns VNF LCM operation occurrence(s) to the SOL003 Adapter
  • 200 OK (VnfLcmOpOcc[])
  • 200 OK (VnfLcmOpOcc)

Precondition: SVNFM performed LCM operations

Postcondition: SOL003 Adapter receives VNF LCM operation occurrence(s)

Heal VNF (SOL003 Adapter → VNFM)

The SOL003 Adapter requests the Heal VNF operation. The following diagram depicts a sequence for the Heal VNF operation.

Note: this is out of Frankfurt scope.

SO Workflows and Java Code (client) Enhancement

SO BPMN Workflows and associated Java code for SOL003 operations will be enhanced and created by leveraging the SOL003 Adapter NBIs.

Enhance Create/Instantiate Workflows & Associated Java Code

• Modify the existing workflow to separate Create and Instantiate tasks
• Invoke the modified SOL003 Adapter NBIs

Precondition: The generic VNF has been added in AAI. The VNF package has been distributed from SDC. The VNFM and VIM have been defined in AAI. VNFM simulator deployed as VNFM. SDNC preload completed through SDNC access site. Add the ETSI "Create_VNF" and "Terminate_VNF" building blocks to the "building_block_detail" table in MariaDB's "catalogdb". Edit the "orchestration_status_state_transition_directive" table in MariaDB's "catalogdb" to allow a service with "operationStatus" set to "CREATED" to allow a building block with a "TARGET_ACTION" of "ACTIVATE" to "CONTINUE".

 Postcondition: Create and instantiate requests were correctly sent to the VNFM, the grant request from the VNFM was handled and reply sent to the VNFM and AAI was updated in accordance with the notifications received from the VNFM as a result of the VNF being instantiated.

Enhance Terminate/Delete Workflows & Associated Java Code

• Modify the existing workflow to separate Terminate and Delete tasks
• Invoke the modified SOL003 Adapter NBIs

Precondition: The VNF has been created via the VNFM adapter

Postcondition: Terminate and delete requests were correctly sent to the VNFM, the grant request from the VNFM was handled and reply sent to the VNFM and AAI was updated in accordance with the notifications received from the VNFM as a result of the VNF being terminated.

Create Query VNF Workflows & Associated Java Code

• Create a new workflow for Query VNF and associated Java code
• Invoke the modified SOL003 Adapter Query VNF NBI

Precondition: VNF is created previously

Postcondition: Query VNF workflow get VNF info

Create Get Operation Status Workflows & Associated Java code

• Create a new Get Operation Status Workflow & Associated Java code
• Invoke the modified SOL003 Adapter Get Operation Status NBI
• This operation could be used by the Instantiation and Termination of VNF; in this case, its workflow could be omitted

Precondition: VNF instantiation or terminate is started

Postcondition: the workflow or the SOL003 Adapter client gets the VnF operation status.

Authentication and Authorization for the SOL003 Adapter and the VNFM

<describe how the SOL003 Adapter and VNFM support security (authentication and authorization) >