SOL003 Adapter - Guilin

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

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 

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

Secured communication and authentication and authorization support

• HTTPS protocol
• Authentication and Authorization support via AAF

Support of ETSI SOL003 v2.7.1 Or-Vnfm Interface from ONAP to external VNF Manager(s)

Support of ETSI SOL003 v2.7.1 Or-Vnfm Interface from ONAP to external VNF Manager(s)

Executive Summary - Provide an interface adapter from ONAP Service Orchestrator to external VNF Manager(s) using  ETSI SOL003 v2.7.1 (Link to ETSI SOL003 v2.7.1) compliant Interface 

• Support for Create, Instantiate, Query of a VNF using an external VNF Manager

• Support for Grant request from an external VNF Manager

• Support for ModifyVnfInfo using an external Manager

• Support for VNF Heal

• Support for VNF Scale (out, in, level)

• Support for Grant with Incremental resource allocation and HPA support using OOF

• Support for received VNF Life Cycle Notifications (LCN) from a VNF Manager and translation into DCAE Events

• Oauth2 based authentication support between ONAP and VNFM(s)

Business Markets - All operators and service providers that are using ETSI SOL003 compliant VNF Managers

Funding/Financial Impacts - Reduction in operations expense from using industry standard Interfaces.

Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. 

SOL003  Adapter NBI Enhancement

Expose the Adapter NBI to any SOL003 Adapter client in ONAP

• Create (Create/Instantiate)

• Create (Create/Instantiate)

• Delete (Terminate/Delete)

• Delete (Terminate/Delete)

• Query

• Query

• Get Operation Status

• Get Operation Status

• Modify

• Modify

• Heal

• Heal VNF (triggered by SOL003 Adapter, not auto-healing)

• Scaling (Stretch goal)

• Scaling (Stretch goal)

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

• 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

• 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

• Create Query VNF Workflows & Associated Java code

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

• 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

• ModifyInfo VNF Workflows & Java code

• ModifyInfo Workflows & Associated Java code

• Heal Workflows & Java code

• Heal Workflows & Java ode
  • Scaling out
  • Scaling in
  • Scaling to level

• Scaling workflows & Java code

• Scaling workflows & Java code

Refactor SOL003 Adapter to organize its modules based on functions

• LCM
• Package Management
• Notification

Enhance SOL003 Adapter VNFM location

• SOL003 Adapter selects the VNFM to use on the first request and create a relationship between the VNFM and the VNF in AAI. for the case, the VNFM is deleted or changed, SOL003 Adapter needs to a re-synch mechanism for VNFM location
• It is an exception handling for VNFM instances 

/vnf_instances

/vnf_instances/{vnfInstanceId}

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.

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.