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


Feature Descriptions

Feature

Description

SOL003 VNFM Adapter NBI Enhancement

SOL003 VNFM Adapter exposes its NBI to any VNFM Adapter Client. 

  • VNFM Adapter will be part of SO microservices, but the adapter can be invoked thru MSB.
  • It is a stepping stone for GNFC to leverage the VNFM Adapter
  • Supports additional NBI operations for the additional SOL003-based SBI
  • Support secured communication protocol and authentication and authorization via AAF
SOL003 Adapter Package Management Support

SOL003 Adapter package management support based on SOL003 APIs

  • Handle SOL003-based VNF package requests from SVNFMs
  • Query VNF packages from the ONAP-ETSI Catalog Manager
  • Provide VNF packages to SVNFMs
Granting EnhancementGranting is enhanced to support HPA by leveraging OOF
Additional of SOL003 operations 

Support of additional SOL003 operations, such as Grant enhancement, Query, Modify, Scale, Operation Status, FM, PM, Heal, VNF Indicator, Retry, Rollback, Failing, Cancelling, Resource Quota Available Notification

  • operation selections and priorities will be determined 
Mapping between SOL001 VNFD and SDC AID DM

The VNFM Adapter needs to handle mapping between SOL001 VNFD and SDC AID DM

  • Not all VNFD needs to be transformed to the SDC AID DM
  • The Adapter will map the model as much as it needs
  • Mapping to the VF-Module is questionable at this time 
Policy-based Scaling (Stretch goal)

Policy-based Scaling with VNF Indicator and VES event handling

  • Currently, SOL001 specifications does not support the VNF indicator configuration. As a result, VNFD-based VNF indicator is not supported; i.e., auto scaling is not yet supported
  • Mapping between VF-Module and ScalingAspect+Data is under discussion. Several VNF vendors indicated that they don't want to handle the VF-Module level.
  • It is a stretch goal for Frankfurt - TBD
Secured communication and authentication and authorization support by SOL003 Adapter

Secured communication and authentication and authorization support

  • HTTPS protocol
  • Authentication and Authorization support via AAF

Epic and User Story

Epic

User Story

Description

In Frankfurt?JIRASize
SOL003 Adapter Enhancement for Frankfurt









Epic: ETSI Alignment Support - SOL003 Adapter Enhancement for FrankfurtYes (partially)


SOL003  Adapter NBI Enhancement

Expose the Adapter NBI to any SOL003 Adapter client in ONAP

No


  • Create (Create/Instantiate)
  • Create (Create/Instantiate)
No


  • Delete (Terminate/Delete)
  • Delete (Terminate/Delete)
No


  • Query
  • Query
No


  • Get Operation Status
  • Get Operation Status
No


  • Modify
  • Modify
No-
  • Heal
  • Heal VNF (triggered by SOL003 Adapter, not auto-healing)
No-
  • Scaling (Stretch goal)
  • Scaling (Stretch goal)
No-

SOL003 Adapter Package Management by leveraging ONAP-ETSI Catalog Manager

Support VNF Package Management interfaces between the SOL003 Adapter and SVNFM (SVNFM → SOL003 Adapter) by leveraging ONAP-ETSI Catalog Manager (SOL003 Adapter → ONAP-ETSI Catalog Mgr)

Yes


  • SOL003 Package Management Swagger update
  • SOL003 Package Management Swagger update
    • SOL003 Package Management Swagger
    • ETSI Catalog Manager Swagger
    • SOL003 Package Management Notification Swagger
Yes


  • Query VNF Package
  • Query VNF Package (SVNFM → SOL003 Adapter & SOL003 Adapter → ETSI Catalog Manager) : query information about one or multiple VNF Package
Yes


  • Read VNFD
  • Read VNFD of an onboarded VNF package : VNFD is returned (SVNFM → SOL003 Adapter & SOL003 Adapter → ETSI Catalog Manager)
  • ETSI Catalog Manager will return a zip file of the Definition directory.
Yes


  • Fetch VNF Package Content
  • Fetch VNF Package (SVNFM → SOL003 Adapter & SOL003 Adapter → ETSI Catalog Manager) : fetch the content of an onboarded VNF package (VNF package file is returned) 
  • Support of the package_contents partial is a stretch goal in Frankfurt. The ETSI Catalog Manager supports fetching package_contents partial by setting the HTTP_RANGE in the request headers when the SOL003 Adapter wants to obtain a single range of bytes from the VNF package file. 
Yes


  • Fetch VNF Package Artifacts
  • Fetch VNF Package Artifacts (SVNFM → SOL003 Adapter & SOL003 Adapter → ETSI Catalog Manager) : fetch an individual artifact contained in an onboarded VNF package
Yes


  • Subscribe
  • Subscribe (SVNFM → SOL003 Adapter & SOL003 Adapter → ETSI Catalog Manager) : subscribe to notifications related to onboarding and/or changes of VNF package
Yes


  • Query Subscription Info
  • Query Subscription Info (SVNFM → SOL003 Adapter)
Yes


  • Terminate/Delete Subscription
  • Terminate/Delete Subscription (SVNFM → SOL003 Adapter)
Yes


  • Notify
  • Notify (SVNFM ← SOL003 Adapter & ETSI Catalog Manager → SOL003 Adapter) : notify about VNF package onboarding or change
Yes


  • SOL003 Adapter Package Management - Get VNF Packages from ONAP-ETSI Catalog Manager
  • This is obsolete, by merge the functions into the above SO-2412 story and sub-tasks.
  • Support the following VNF Package management (SOL003 Adapter → ONAP-ETSI Catalog Manager). ETSI Catalog Manager will return the original vendor package to the Adapter.
    • Query VNF Package (/api/catalog/v1/vnfpackages)
    • Read VNFD   // get the VNF package and extract VNFD model (sample )
    • Fetch VNF package content
    • Fetch VNF package artifacts
    • subscribe
    • Notify
No


SOL003 Adapter Grant Enhancement that supports HPA by leveraging OOF VNF Granting that supports HPA by leveraging OOFYes


SOL003 Adapter Enhancement for VNF QueryTo invoke VNF QueryNo


SOL003 Adapter Enhancement for VNF Operation Status To invoke Operation StatusNo


SOL003 Adapter Enhancement for VNF ModifyTo invoke VNF ModifyNo

-


SOL003 Adapter Enhancement for VNF HealTo invoke VNF HealNo-
SOL003 Adapter Enhancement for VNF Scaling (Stretch goal)to support Policy-based VNF Scaling support; Interface to DCAE for VES eventNo-
Secured communication support between SOL003 Adapter and SVNFMSecured communication between SOL003 Adapter and SVNFMYes (minimum)


Authentication and authorization support between between SOL003 Adapter and SVNFMAuthentication and authorization support between between SOL003 Adapter and SVNFMYes (minimum)


Preload using user_param (without UI changes)Preload using user_param (without UI changes)Yes


SO BPPN Workflows & Java for SOL003 Operations

SO BPMN Workflows & Java for SOL003 Operations by leveraging the SOL003 Adapter NBIs

No


  • Enhance Create/Instantiate Workflows & Associated Java code
  • Enhance Create/Instantiate Workflows & Associated Java code
    • Modify the existing workflow to separate Create and Instantiate tasks
    • Invoke the modified SOL003 Adapter NBIs
No


  • Enhance Terminate/Delete Workflows & Associated Java code
  • Enhance Terminate/Delete Workflows & Associated Java code
    • Modify the existing workflow to separate Terminate and Delete tasks
    • Invoke the modified SOL003 Adapter NBIs
No


  • Create Query VNF Workflows & Associated Java code
  • Create Query VNF Workflows & Associated Java code
    • Invoke the modified SOL003 Adapter Query VNF NBI
No


  • Create Get Operation Status Workflows & Associated Java code
  • Create Get Operation Status Workflows & 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
No


CSIT enhancement for testing SOL003 Adapter package management enhancementCSIT enhancement for testing SOL003 Adapter package management enhancementNo


Documentation for SOL003 Adapter enhancement featuresDocumentation for SOL003 Adapter enhancement featuresNO



SOL003 VNFM Adapter Architecture for Frankfurt

The diagram depicts SOL003 VNFM Adapter Architecture.


  1. SOL003 Adapter continues to be an SO microservice component, and exposes its NBI to any SOL003 Adapter client in ONAP
  2. SOL003 Adapter is registered to MSB.
  3. Operator registers VNFM and VIM to ESR in AAI.
  4. SOL003 Adapter exposes its NBI to any SOL003 Adapter client in ONAP (not for Frankfurt)
    1. Interfaces will be refactored to be generic to allow access by other ONAP components.
    2. The NBI will be enhanced for additional SOL003 operation support
  5. SDC distributes SDC packages including the vendor original SOL004 (VNF and PNF) and SOL007 (NS) packages – SOL007 is not for Frankfurts
  6. SO (SDC Controller) passes the SDC CSAR ID to ETSI Catalog Manager to invoke storage
  7. ETSI Catalog Manager queries for SDC CSAR with the SDC CSAR id & store SOL004/SOL007 package.
  8. SO (BPMN) and the SOL003 Adapter client locates SOL003 Adapter.
  9. SO (BPMN) and the SOL003 Adapter client invokes SOL003 Adapter.
  10. SOL003 Adapter retrieves VNF package from Catalog Manager.
  11. SOL003 Adapter gets available VNFM locations (endpoints) and gets VIM and VNF Info.
  12. SOL003 Adapter selects a VNFM, based on a VNFM locating mechanism.
  13. SOL003 Adapter and SVNFM supports SOL003 VNF LCM, granting and package management operations.
  14. SOL003 Adapter supports HPA-based Granting, leveraging OOF.
  15. SOL003 Adapter updates vServer, status and VNF association in AAI
  16. SOL003 Adapter and SVNFM support authentication and authorization (AAF, and vendor AA mechanism) – partially for Frankfurt.
  17. For integration testing, the VNFM Simulator is used.


SOL003 Operations

The following SOL003 operations will be supported:

SOL003-based Operation Sequence Flows


@startuml
participant VID
participant SO_BPMN
participant SOL003_Adapter
participant ONAP_ETSI_Catalog_Mgr
participant AAI
participant OOF
participant VNFM
autonumber 

	VID -> SO_BPMN : Create VNF
	SO_BPMN -> SOL003_Adapter : Create
	SOL003_Adapter -> AAI : Get Generic VNF using ID \nfrom create request
	AAI -> SOL003_Adapter : Response with Generic VNF
	SOL003_Adapter -> AAI : Get VNFMs
	AAI -> SOL003_Adapter : Response with VNFMs
	SOL003_Adapter --> SOL003_Adapter : Select VNFM using nf type\n from Generic VNF
	SOL003_Adapter -> ONAP_ETSI_Catalog_Mgr : Get package using Model ID from Generic VNF
	ONAP_ETSI_Catalog_Mgr -> SOL003_Adapter : Response with VNF Package
	SOL003_Adapter -> VNFM : Send Create to SVNFM
	VNFM --> VNFM : Create the VNF ID
	VNFM -> SOL003_Adapter : Response with VNF ID
	SOL003_Adapter -> AAI : Update Generic VNF with self link.\nAdd relationship from Generic VNF\nto VNFM and Tenant
	SOL003_Adapter -> VNFM : Subscribe for notifications\nrelated to the created VNF
	VNFM -> SOL003_Adapter : Response for subscription
	SOL003_Adapter -> VNFM : Send Instantiate to SVNFM
	VNFM --> VNFM : Start Instantiation
	VNFM -> SOL003_Adapter : Response with Operation ID
	SOL003_Adapter -> ONAP_ETSI_Catalog_Mgr : Add Operation ID
	SOL003_Adapter -> SO_BPMN : Response with Job ID
	VNFM -> SOL003_Adapter : Send Grant Request
alt resource-level HPA
	SOL003_Adapter -> OOF : Request for HPA homing information
	OOF -> SOL003_Adapter : Response with homing information
else SO cashes Homing Info at the Service level
    SOL003_Adapter --> SOL003_Adapter : get HPA homing information from SO/SOL003 Adapter cache
end
	SOL003_Adapter -> VNFM : Send Grant Response
	VNFM --> VNFM : Instantiate VNF on VIM
	VNFM -> SOL003_Adapter : Send operation completed notification
	SOL003_Adapter -> AAI : Add vserver info, update orchestration\nstatus of Generic VNF
	SO_BPMN -> SOL003_Adapter : Get Job Status
	SOL003_Adapter -> VNFM : Query Operation Status
	VNFM -> SOL003_Adapter : Response with Operation Status
	SOL003_Adapter -> SO_BPMN : Response with Status
	SO_BPMN -> VID : Create VNF is done


@enduml

<Diagram : tbd>


SOL003 Adapter - SVNFM - ETSI Catalog Manager Operations

The SOL003 Adapter supports the following SOL003-based operations.

Operation Interfaces Requirements

API Action

Actor

Method

URI

Description

Query VNF PackageVNFM → SOL003 AdapterGET
/vnf_packages, /vnf_packages/{vnfPkgId}
To query VNF packages or individual packages
Read VNFDVNFM → SOL003 AdapterGET
/vnf_packages/{vnfPkgId}/vnfd
To read VNFD
Fetch VNF PackageVNFM → SOL003 AdapterGET
/vnf_packages/{vnfPkgId}/package_content

To fetch a VNF package

Fetch VNF Package ArtifactVNFM → SOL003 AdapterGET
/vnf_packages/{vnfPkgId}/artifacts/{artifactPath}
To fetch a VNF package artifact
Create Subscription for Package ManagementVNFM → SOL003 AdapterPOST/subscription (PkgmSubscriptionRequest)To create a subscription for package management
Sending Notification for Package ManagementSOL003 Adapter → VNFMPOST<<Client side URL>> (<<Notification>>)To post a notification for package management
Grant Request VNFM → SOL003 AdapterPOST/grants/ (GrantRequest)To get VNF granting
Query VNFSOL003 Adapter → VNFMGET

/vnf_instances

/vnf_instances/{vnfInstanceId}

To get VNF instances or a VNF instance
Modify VNFSOL003 Adapter → VNFMPATCH/vnf_instances/{vnfInstanceId} (VnfInfoModificationRequest)To modify VNF instances
Get Operation StatusSOL003 Adapter → VNFMGET/vnf_lcm_op_occsTo get VNF operation status


Package Management


@startuml
participant VNFM
participant SOL003_Adapter
participant ONAP_ETSI_Catalog_Mgr
autonumber 

	hnote over VNFM, SOL003_Adapter : Precondition: One or more individual VNF package resources are created.
alt query information about multiple VNF packages
	VNFM -> SOL003_Adapter : GET .../vnf_packages
	SOL003_Adapter -> ONAP_ETSI_Catalog_Mgr : GET /api/vnfpkgm/v1/vnf_packages/
	ONAP_ETSI_Catalog_Mgr -> SOL003_Adapter : 200 OK (VnfPkgInfo[])
	SOL003_Adapter -> VNFM: 200 OK (VnfPkgInfo[])
else read information about individual VNF package
	VNFM -> SOL003_Adapter : GET .../vnf_packages/{vnfPkgId}
	SOL003_Adapter -> ONAP_ETSI_Catalog_Mgr : GET /api/vnfpkgm/v1/vnf_packages/{vnfPkgId}
	ONAP_ETSI_Catalog_Mgr -> SOL003_Adapter : 200 OK (VnfPkgInfo)
	SOL003_Adapter -> VNFM: 200 OK (VnfPkgInfo)	
end

@enduml



@startuml
participant VNFM
participant SOL003_Adapter
participant ONAP_ETSI_Catalog_Mgr
autonumber 

	hnote over VNFM, SOL003_Adapter : Precondition: The VNF package is onboarded to the ONAP_ETSI_Catalog_Mgr.
	VNFM -> SOL003_Adapter : GET .../vnf_packages/{vnfPkgId}/vnfd
	SOL003_Adapter -> ONAP_ETSI_Catalog_Mgr : GET /api/vnfpkgm/v1/vnf_packages/{vnfPkgId}/vnfd
	ONAP_ETSI_Catalog_Mgr -> SOL003_Adapter : 200 OK (Vnfd) \n
	SOL003_Adapter -> VNFM: 200 OK (Vnfd)

@enduml


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

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


@startuml
participant VNFM
participant SOL003_Adapter
participant ONAP_ETSI_Catalog_Mgr
autonumber 

	hnote over VNFM, SOL003_Adapter : Precondition: The VNF package is onboarded to the ONAP_ETSI_Catalog_Mgr.
alt fetch the whole VNF package content
	VNFM -> SOL003_Adapter : GET .../vnf_packages/{vnfPkgId}/package_content
	SOL003_Adapter -> ONAP_ETSI_Catalog_Mgr : GET /api/vnfpkgm/v1/vnf_packages/{vnfPkgId}/package_content
	ONAP_ETSI_Catalog_Mgr -> SOL003_Adapter : 200 OK (VNF package file)
	SOL003_Adapter -> VNFM: 200 OK (VNF package file)
else fetch the VNF package content using partial download
	VNFM -> SOL003_Adapter : GET .../vnf_packages/{vnfPkgId}/package_content (Range: bytes=xxx-yyy)
	SOL003_Adapter -> ONAP_ETSI_Catalog_Mgr : GET /api/vnfpkgm/v1/vnf_packages/{vnfPkgId}/package_content (Range: bytes=xxx-yyy)
	ONAP_ETSI_Catalog_Mgr -> SOL003_Adapter : 206 Partial Content (Content-Range: bytes=xxx-yyy/zzz, Partial content of the VNF package file)
	SOL003_Adapter -> VNFM: 206 Partial Content (Content-Range: bytes=xxx-yyy/zzz, Partial content of the VNF package file)
end

@enduml

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

Postcondition: the SVNF gets the applicable artifact file.


@startuml
participant VNFM
participant SOL003_Adapter
participant ONAP_ETSI_Catalog_Mgr
autonumber 

	hnote over VNFM, SOL003_Adapter : Precondition: The VNF package is onboarded to the ONAP_ETSI_Catalog_Mgr.
alt fetch the whole content of the artifact
	VNFM -> SOL003_Adapter : GET .../vnf_packages/{vnfPkgId}/artifacts/{artifactPath}
	SOL003_Adapter -> ONAP_ETSI_Catalog_Mgr : GET /api/vnfpkgm/v1/vnf_packages/{vnfPkgId}/artifacts/{artifactPath}
	ONAP_ETSI_Catalog_Mgr -> SOL003_Adapter : 200 OK (artifact file)
	SOL003_Adapter -> VNFM: 200 OK (artifact file)
else fetch the artifact using partial download
	VNFM -> SOL003_Adapter : GET .../vnf_packages/{vnfPkgId}/artifacts/{artifactPath} (Range: bytes=xxx-yyy)
	SOL003_Adapter -> ONAP_ETSI_Catalog_Mgr : GET /api/vnfpkgm/v1/vnf_packages/{vnfPkgId}/artifacts/{artifactPath} (Range: bytes=xxx-yyy)
	ONAP_ETSI_Catalog_Mgr -> SOL003_Adapter : 206 Partial Content (Content-Range: bytes=xxx-yyy/zzz, Partial content of the artifact file)
	SOL003_Adapter -> VNFM: 206 Partial Content (Content-Range: bytes=xxx-yyy/zzz, Partial content of the artifact file)
end

@enduml

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)

<Sequence Diagram SVNFM → SOL003 Adapter>


@startuml
participant VNFM
participant SOL003_Adapter
autonumber 

	VNFM -> SOL003_Adapter : POST .../subscription (PkgmSubscriptionRequest)
opt 
	hnote over SOL003_Adapter : test notification endpoint
	SOL003_Adapter -> VNFM : GET <<<Client side URI>>
	VNFM -> SOL003_Adapter : 204 No Content
end
	SOL003_Adapter --> SOL003_Adapter : Create subscription resource
	SOL003_Adapter -> VNFM : 201 Created (PkgmSubscription)
opt
	hnote over VNFM : Client re-synchronizes all\nor selected subscriptions\ne.g., after an error
	VNFM -> SOL003_Adapter : GET .../subscriptions/
	SOL003_Adapter -> VNFM : 200 OK (PkgmSubscription[])
	VNFM -> SOL003_Adapter : GET .../subscription/{subscriptionId}
	SOL003_Adapter -> VNFM : 200 OK (PkgmSubscription)
end
	hnote over VNFM : Client does not need the\nsubscription anymore
	VNFM -> SOL003_Adapter : DELETE .../subscription/{subscriptionId}
	SOL003_Adapter -> VNFM : 204 No content

@enduml


<Sequence Diagram SOL003 Adapter → ETSI_Catalog_Manager>


@startuml
participant ETSI_Catalog_Mgr
participant SOL003_Adapter
autonumber 

	SOL003_Adapter -> ETSI_Catalog_Mgr : POST .../api/vnfpkgm/v1/subscriptions (PkgmSubscriptionRequest)
opt 
	hnote over ETSI_Catalog_Mgr : test notification endpoint
	ETSI_Catalog_Mgr -> SOL003_Adapter : GET <<<Client side URI>>
	SOL003_Adapter -> ETSI_Catalog_Mgr : 204 No Content
end
	ETSI_Catalog_Mgr --> ETSI_Catalog_Mgr : Create subscription resource
	ETSI_Catalog_Mgr -> SOL003_Adapter : 201 Created (PkgmSubscription)
opt
	hnote over SOL003_Adapter : Client re-synchronizes all\nor selected subscriptions\ne.g., after an error
	SOL003_Adapter -> ETSI_Catalog_Mgr : GET .../subscriptions/
	ETSI_Catalog_Mgr -> SOL003_Adapter : 200 OK (PkgmSubscription[])
	SOL003_Adapter -> ETSI_Catalog_Mgr : GET .../subscription/{subscriptionId}
	ETSI_Catalog_Mgr -> SOL003_Adapter : 200 OK (PkgmSubscription)
end
	hnote over SOL003_Adapter : Client does not need the\nsubscription anymore
	SOL003_Adapter -> ETSI_Catalog_Mgr : DELETE .../subscription/{subscriptionId}
	ETSI_Catalog_Mgr -> SOL003_Adapter : 204 No content

@enduml


Precondition: SVNFM lost package subscription information

Postcondition: SVNFM gets package subscription information


@startuml
participant VNFM
participant SOL003_Adapter
autonumber 

hnote over VNFM : Precondition the client has subscribed for notification
opt
	hnote over VNFM : Client re-synchronizes all\nor selected subscriptions\ne.g., after an error
	VNFM -> SOL003_Adapter : GET .../subscriptions/
	SOL003_Adapter -> VNFM : 200 OK (PkgmSubscription[])
	VNFM -> SOL003_Adapter : GET .../subscription/{subscriptionId}
	SOL003_Adapter -> VNFM : 200 OK (PkgmSubscription)
end
	

@enduml



Precondition: SVNFM subscribed to the SOL003 Adapter for package notifications

Postcondition: SOL003 Adapter removed the SVNFM package subscription.


@startuml
participant VNFM
participant SOL003_Adapter
autonumber 

	VNFM -> SOL003_Adapter : POST .../subscription (PkgmSubscriptionRequest)
opt 
	hnote over SOL003_Adapter : test notification endpoint
	SOL003_Adapter -> VNFM : GET <<<Client side URI>>
	VNFM -> SOL003_Adapter : 204 No Content
end
	SOL003_Adapter --> SOL003_Adapter : Create subscription resource
	SOL003_Adapter -> VNFM : 201 Created (PkgmSubscription)
opt
	hnote over VNFM : Client re-synchronizes all\nor selected subscriptions\ne.g., after an error
	VNFM -> SOL003_Adapter : GET .../subscriptions/
	SOL003_Adapter -> VNFM : 200 OK (PkgmSubscription[])
	VNFM -> SOL003_Adapter : GET .../subscription/{subscriptionId}
	SOL003_Adapter -> VNFM : 200 OK (PkgmSubscription)
end
	hnote over VNFM : Client does not need the\nsubscription anymore
	VNFM -> SOL003_Adapter : DELETE .../subscription/{subscriptionId}
	SOL003_Adapter -> VNFM : 204 No content

@enduml


Precondition: SVNFM has subscribed to the SOL003 Adapter previously

                        SOL003 Adapter subscribed to the ETSI Catalog Manager previously

Postcondition: SVNFM receives a notification


@startuml
participant VNFM
participant SOL003_Adapter
autonumber 

	hnote over VNFM, SOL003_Adapter : Precondition: VNFM has subscribed previously
	hnote over SOL003_Adapter : Event occurs that\nmatches subscription\n(e.g., SOL003_Adapter receives notifications from the ONAP-ETSI Catalog Manager)
	SOL003_Adapter -> VNFM : POST <<Client side URL>> (<<Notification>>)
	VNFM -> SOL003_Adapter : 204 No Content

@enduml


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. In the Frankfurt release, only the Method 1 will be supported.

Postcondition: SVNFM receives a granting


@startuml
participant CLIENT
participant SO
participant AAI
participant OOF
participant SOL003_Adapter
participant VNFM
autonumber 

group SERVICE CREATION REQUEST
	hnote over SO : SO/CLIENT API
	hnote over CLIENT : Svc Model ID, input parameters, Recipe ID
	CLIENT -> SO : Service Creation Request	
end

group INVENTORY RECORD CREATION
	hnote over AAI : AAI API
	SO -> AAI : Inventory Record Creation Request
	AAI -> AAI : Create Inventory Record
	hnote over AAI: INVENTORY RECORD
	AAI -> SO : Inventory Record Creation Response	
end

group HOMING REQUEST
	hnote over SO : xNF Resources, Service ID
	SO -> OOF : Homing Assignment Request\n (Service-level)
	OOF --> OOF: Homing Assignment
	OOF -> SO : Homing Assignment Response\n (Service and underneath resource Homing)
    SO -> SOL003_Adapter : SO workflow Passes homing information to SOL003 Adapter as part of request
end
	VNFM -> SOL003_Adapter : Request for Granting\nPOST .../grants/ (GrantRequest)
	SOL003_Adapter --> SOL003_Adapter : Get the VNF homing information from the request parameters
	SOL003_Adapter -> VNFM : Response with a Granting decision\n201 Created (Grant)

@enduml



@startuml
participant VNFM
participant SOL003_Adapter
participant OOF_OSDF
participant OOF_HAS
participant Policy
participant AAI
participant MultiCloud

autonumber 

	VNFM -> SOL003_Adapter : Request for Granting\nPOST .../grants/ (GrantRequest)
	SOL003_Adapter -> OOF_OSDF : Request for Homing
	OOF_OSDF -> Policy : Request for the related homing constraints/policies
	Policy -> OOF_OSDF : Response with the related homing constraints/policies
	OOF_OSDF -> OOF_HAS : Request for further homing information
	OOF_HAS -> AAI : Request for pulling all available cloud-regions,\and nservice & resource information\n(existing instances of VNFs/services)
	AAI -> OOF_HAS : response with cloud-region,\n and service & resource information
	OOF_HAS -> MultiCloud : Request for cloud agnostic and capacity information \n(vims which fulfill the requirements)
	MultiCloud -> OOF_HAS : Response with cloud agnostic and capacity information
	OOF_HAS -> OOF_OSDF : Response with homing information
	OOF_OSDF --> OOF_OSDF : Find optimal placements for the service
	OOF_OSDF -> SOL003_Adapter : Response with optimal placement information
	SOL003_Adapter -> VNFM : Response with a Granting decision\n201 Created (Grant)

@enduml


GrantRequest Structure

Attribute name

Data type

Cardinality

Description

vnfInstanceId

Identifier

1

Identifier of the VNF instance which this grant request is related to. Shall also be provided for VNFs that not yet exist but are planned to exist in the future, i.e. if the grant is requested for InstantiateVNF.

vnfLcmOpOccId

Identifier

1

The identifier of the VNF lifecycle management operation occurrence associated to the GrantRequest.

vnfdId

Identifier

1

Identifier of the VNFD that defines the VNF for which the LCM operation is to be granted.

flavourId

Identifier

0..1

Identifier of the VNF deployment flavour of the VNFD that defines the VNF for which the LCM operation is to be granted.
Shall be provided when instantiating the VNF or changing the deployment flavour of the VNF instance.

operation

GrantedLcmOperationType

1

The lifecycle management operation for which granting is requested. See note 1.

isAutomaticInvocation

Boolean

1

Set to true if this VNF LCM operation occurrence has been triggered by an automated procedure inside the VNFM (i.e. ScaleVnf / ScaleVnfToLevel triggered by auto-scale, or HealVnf triggered by auto- heal).

Set to false otherwise.

instantiationLevelId

Identifier

0..1

If operation=INSTANTIATE, the identifier of the instantiation level may be provided as an alternative way to define the resources to be added. This attribute shall only be used if operation=INSTANTIATE.

See note 2.

addResources

ResourceDefinition

0..N

List of resource definitions in the VNFD for resources to be added by the LCM operation which is related to this grant request, with one entry per resource.

See note 2.

tempResources

ResourceDefinition

0..N

List of resource definitions in the VNFD for resources to be temporarily instantiated during the runtime of the LCM operation which is related to this grant request, with one entry per resource. See note 3.

removeResources

ResourceDefinition

0..N

Provides the definitions of resources to be removed by the LCM operation which is related to this grant request, with one entry per resource.

updateResources

ResourceDefinition

0..N

Provides the definitions of resources to be modified by the LCM operation which is related to this grant request, with one entry per resource.

placementConstraints

PlacementConstraint

0..N

Placement constraints that the VNFM may send to the NFVO in order to influence the resource placement decision. If sent, the NFVO shall take the constraints into consideration when making resource placement decisions, and shall reject the grant if they cannot be honoured. See note 4 and note 5.

vimConstraints

VimConstraint

0..N

Used by the VNFM to require that multiple resources are managed through the same VIM connection. If sent, the NFVO shall take the constraints into consideration when making VIM selection decisions, and shall reject the grant if they cannot be honoured.

This attribute shall be supported if VNF- related Resource Management in direct mode is applicable.

The applicability and further details of this attribute for indirect mode are left for future specification.

additionalParams

KeyValuePairs

0..1

Additional parameters passed by the VNFM, specific to the VNF and the LCM operation.

_links

Structure (inlined)

1

Links to resources related to this request.

>vnfLcmOpOcc

Link

1

Related lifecycle management operation occurrence.

>vnfInstance

Link

1

Related VNF instance.

NOTE 1: NOTE 2: NOTE 3:

NOTE 4: NOTE 5:

The VNF LCM operations CreateVnfIdentifier, DeleteVnfIdentifier, QueryVnf and ModifyVnfInformation can be executed by the VNFM without requesting granting.
If the granting request is for InstantiateVNF, either instantiationLevel or addResources shall be present.
The NFVO will assume that the VNFM will be responsible to both allocate and release the temporary resource during the runtime of the LCM operation. This means, the resource can be allocated and consumed after the "start" notification for the LCM operation is sent by the VNFM, and the resource will be released before the "result" notification of the VNF LCM operation is sent by the VNFM.
The affinity/anti-affinity rules defined in the VNFD , and the placement constraints in the GrantVnfLifecycleOperation as defined in this clause should be conflict-free. In case of conflicts, the placement constraints in the GrantVnfLifecycleOperation shall take precedence.
Passing constraints allows the VNFM or the lifecycle management scripts to influence resource placement decisions by the NFVO to ensure VNF properties such as performance or fault tolerance.


Grant Structure

Attribute name

Data type

Cardinality

Description

id

Identifier

1

Identifier of the grant.

vnfInstanceId

Identifier

1

Identifier of the related VNF instance.

vnfLcmOpOccId

Identifier

1

Identifier of the related VNF lifecycle management operation occurrence.

vimConnections

VimConnectionInfo

0..N

Provides information regarding VIM connections that are approved to be used by the VNFM to allocate resources, and provides parameters of these VIM connections.

The VNFM shall update the " vimConnectionInfo" attribute of the "VnfInstance" structure by adding unknown entries received in this attribute.

This attribute is not intended for the modification of VimConnection entries passed earlier; for that, the VnfInfoModificationRequest structure shall be used.

This attribute shall only be supported when VNF-related Resource Management in direct mode is applicable. In direct mode, this parameter shall be absent if the VIM information was configured to the VNFM in another way, present otherwise.

See note 1.

zones

ZoneInfo

0..N

Identifies resource zones where the resources are approved to be allocated by the VNFM.

zoneGroups

ZoneGroupInfo

0..N

Information about groups of resource zones that are related and that the NFVO has chosen to fulfil a zoneGroup constraint in the GrantVnfLifecycleOperation request. This information confirms that the NFVO has honoured the zoneGroup constraints that were passed as part of "placementConstraints" in the GrantRequest.

computeReservationId

IdentifierInVim

0..1

Information that identifies a reservation applicable to the compute resource requirements of the corresponding grant request. See note 2.

networkReservationId

IdentifierInVim

0..1

Information that identifies a reservation applicable to the network resource requirements of the corresponding grant request. See note 2.

storageReservationId

IdentifierInVim

0..1

Information that identifies a reservation applicable to the storage resource requirements of the corresponding grant request. See note 2.

addResources

GrantInfo

0..N

List of resources that are approved to be added, with one entry per resource.

tempResources

GrantInfo

0..N

List of resources that are approved to be temporarily instantiated during the runtime of the lifecycle operation, with one entry per resource.

removeResources

GrantInfo

0..N

List of resources that are approved to be removed, with one entry per resource.

updateResources

GrantInfo

0..N

List of resources that are approved to be modified, with one entry per resource.

vimAssets

Structure (inlined)

0..1

Information about assets for the VNF that are managed by the NFVO in the VIM, such as software images and virtualised compute resource flavours.

This attribute is not intended for the modification of vimAssets entries passed earlier. See note 3.

>computeResourceFlavours

VimComputeResourceFlavour

0..N

Mappings between virtual compute descriptors defined in the VNFD and compute resource flavours managed in the VIM.

>softwareImages

VimSoftwareImage

0..N

Mappings between software images defined in the VNFD and software images managed in the VIM.

extVirtualLinks

ExtVirtualLinkData

0..N

Information about external VLs to connect the VNF to. See note 5.

extManagedVirtualLinks

ExtManagedVirtualLinkData

0..N

Information about internal VLs that are managed by other entities than the VNFM. See note 4 and note 5.

additionalParams

KeyValuePairs

0..1

Additional parameters passed by the NFVO, specific to the VNF and the LCM operation.

_links

Structure (inlined)

1

Links to resources related to this resource.

>self

Link

1

URI of this resource.

>vnfLcmOpOcc

Link

1

Related VNF lifecycle management operation occurrence.

>vnfInstance

Link

1

Related VNF instance.

NOTE 1: NOTE 2:

NOTE 3: NOTE 4:

NOTE 5:

This interface allows to signal the use of multiple VIMs per VNF. However, due to the partial support of this feature in the present release, it is recommended in the present document that the number of entries in the "vims" attribute in the Grant is not greater than 1.
At least one of (computeReservationId, networkReservationId, storageReservationId) shall be present when policy is GRANT_RESERVE_SINGLE and an applicable reservation exists. None of these shall be present otherwise.

Modification of VIM assets during the lifetime of a VNF instance is not necessary, since it is expected that all applicable assets have been on boarded into the VIM before the VNF is instantiated.
The indication of externally-managed internal VLs is needed in case networks have been pre- configured for use with certain VNFs, for instance to ensure that these networks have certain properties such as security or acceleration features, or to address particular network topologies. The present document assumes that externally-managed internal VLs are managed by the NFVO and created towards the VIM.

External and/or externally-managed internal VLs can be passed in VNF lifecycle management operation requests such as InstantiateVnf or ChangeVnfFlavor, and/or in the grant response. The NFVO may choose to override in the grant response external and/or externally-managed VL instances that have been passed previously in the associated VNF lifecycle management request, if the lifecycle management request has originated from the NFVO itself.

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.


@startuml
participant Vendor
participant Service_Architect
participant Operator_Administrator
participant SDC
participant Policy_Framework

autonumber 

	Vendor -> SDC : specify homing policies related to VNF.\nE.g., hardware requirements like \nCPU pinning, NUMA, SRIOV, etc. (VNFD)
	Service_Architect -> SDC : specify homing policies for a given service\n like vCPE. Policies may relate one or more VNFs \nthat constitutes the service. \nE.g., distance thresholds between two VNFs of \na service, minimizing distance between customer and VNF, etc.  (NSD)
	Operator_Administrator -> Policy_Framework : specify homing policies that are overarching \nacross multiple services. \nE.g., given two placements that are equally \nperformant pick the one with lowest cost, \nno cloud-region should have more than x% over-subscription. 
	SDC -> Policy_Framework : Distribution

@enduml


<describe further>



Query VNF (SOL003 Adapter → VNFM)

Precondition: VNF instance is created

Postcondition: SOL003 Adapter gets VnfInstance[] or VnfInstance


@startuml
participant SOL003_Adapter
participant VNFM
autonumber 

	hnote over SOL003_Adapter, VNFM : Precondition: VNF instance is created
alt query information about multiple VNF instances
	SOL003_Adapter -> VNFM : GET .../vnf_instances
	VNFM -> SOL003_Adapter : 200 OK (VnfInstance[])
else read information about individual VNF instance
	SOL003_Adapter -> VNFM : GET .../vnf_instances/{vnfInstanceId}
	VNFM -> SOL003_Adapter : 200 OK (VnfInstance)
end

@enduml


Modify VNF (SOL003 Adapter → VNFM)

The SOL003 Adapter requests the Modify VNF to the VNFM.

Note: it is out of Frankfurt scope.


@startuml
participant SOL003_Adapter
participant VNFM
autonumber 

	hnote over SOL003_Adapter, VNFM : Precondition: VNF instance resource has been created.
	SOL003_Adapter -> VNFM : PATCH .../vnf_instances/{vnfInstanceId} (VnfInfoModificationRequest)
	VNFM --> VNFM : Create VNF LCM operation\noccurrence resource for this request
	VNFM -> SOL003_Adapter : 202 Accepted ()
	VNFM -> SOL003_Adapter : Send VnfLcmOperationOccurrenceNotification (Start)
opt
	SOL003_Adapter -> VNFM : GET .../vnf_lcm_op_occs/{vnfLcmOpOccId}
	VNFM -> SOL003_Adapter : 200 OK (VnfLcmOpOcc:operationStatus=PROCESSING)
end
	VNFM --> VNFM : Modification finished
	VNFM -> SOL003_Adapter : Send VnfLcmOperationOccurrenceNotification (result)
opt
	SOL003_Adapter -> VNFM : GET .../vnf_lcm_op_occs/{vnfLcmOpOccId}
	VNFM -> SOL003_Adapter : 200 OK (VnfLcmOpOcc:operationStatus=COMPLETED)
end
	hnote over SOL003_Adapter, VNFM : Postcondition: The VNF instance information is updated.

@enduml

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


Precondition: SVNFM performed LCM operations

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


@startuml
participant SOL003_Adapter
participant VNFM
autonumber 

alt query information about multiple VNF LCM operation occurrences
	SOL003_Adapter -> VNFM : GET .../vnf_lcm_op_occs
	VNFM -> SOL003_Adapter : 200 OK (VnfLcmOpOcc[])
else read information about individual VNF LCM operation occurrence
	SOL003_Adapter -> VNFM : GET .../vnf_lcm_op_occs/{vnfLcmOpOccId}
	VNFM -> SOL003_Adapter : 200 OK (VnfLcmOpOcc)
end

@enduml


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.


@startuml
participant SOL003_Adapter
participant VNFM
autonumber 

	hnote over SOL003_Adapter, VNFM : Precondition: VNF instance in INSTANTIATED state.
	SOL003_Adapter -> VNFM : POST .../vnf_instances/{vnfInstanceId}/heal (HealVnfRequest)
	VNFM --> VNFM : Create VNF LCM operation occurrence resource for this request
	VNFM -> SOL003_Adapter : 202 Accepted()
	VNFM -> SOL003_Adapter : Send VnfLcmOperationOccurrenceNotification(STARTING)
	VNFM -> SOL003_Adapter : request for granting
	SOL003_Adapter -> VNFM : granting response
opt
	SOL003_Adapter -> VNFM : GET ../vnf_lcm_op_occs/{vnfLcmOpOccId}
	VNFM -> SOL003_Adapter : 200 OK (VnfLcmOpOCC:operationState=PROCESSING)
end

	VNFM --> VNFM : <<opeation>> finished
	VNFM -> SOL003_Adapter : Send VnfLcmOperationOccurrenceNotification(COMPLETED)
opt
	SOL003_Adapter -> VNFM : GET ../vnf_lcm_op_occs/{vnfLcmOpOccId}
	VNFM -> SOL003_Adapter : 200 OK (VnfLcmOpOCC:operationState=COMPLETED)
end
	hnote over SOL003_Adapter, VNFM : Postcondition: VNF instance in INSTANTIATED state,\nVNF instance was healed

@enduml


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

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

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

Precondition: VNF is created previously

Postcondition: Query VNF workflow get VNF info

Create Get Operation Status Workflows & Associated Java code

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