Merge branch '3.5.1-dev' of https://forge.etsi.org/gitlab/nfv/SOL002-SOL003 into 3.5.1-dev (18886948) · Commits · Miguel Angel Reina Ortega / SOL002-SOL003

src/SOL003/VNFLifecycleManagement/definitions/SOL003VNFLifecycleManagement_def.yaml

+361 −394

File changed.

Preview size limit exceeded, changes collapsed.

src/SOL003/VNFLifecycleOperationGranting/definitions/SOL003VNFLifecycleOperationGranting_def.yaml

+90 −200

Original line number	Original line	Diff line number	Diff line
	@@ -4,7 +4,26 @@
	definitions:		definitions:
	GrantRequest:		GrantRequest:
	description: >		description: >
	This type represents a grant request.		This type represents a grant request. It shall comply with the provisions defined in table 9.5.2.2-1.

			NOTE 1: The VNF LCM operations CreateVnfIdentifier, DeleteVnfIdentifier, QueryVnf and ModifyVnfInformation
			can be executed by the VNFM without requesting granting.
			NOTE 2: If the granting request is for InstantiateVNF, either instantiationLevel or addResources shall be present.
			NOTE 3: 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.
			NOTE 4: 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.
			NOTE 5: 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.
			NOTE 6: If fallbackBestEffort is present in placement constraints and set to "true", the NFVO shall process the Affinity/AntiAffinity
			constraint in a best effort manner, in which case, if specified resources cannot be allocated based on specified placement
			constraint, the NFVO looks for an alternate best effort placement for the specified resources to be granted.
			In the best effort anti-affinity case, the resources are expected to be spread optimally over all available instances of scope
			(e.g. zones), and in the best effort affinity case, they are expected to be distributed optimally over fewer possible instances
			of scope.
	type: object		type: object
	required:		required:
	- vnfInstanceId		- vnfInstanceId
	@@ -50,10 +69,7 @@ definitions:
	$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"
	operation:		operation:
	description: >		description: >
	The lifecycle management operation for which granting is requested.		The lifecycle management operation for which granting is requested. See note 1.
	The VNF LCM operations CreateVnfIdentifier, DeleteVnfIdentifier,
	QueryVnf and ModifyVnfInformation can be executed by the VNFM
	without requesting granting.
	$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/GrantedLcmOperationType"		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/GrantedLcmOperationType"
	isAutomaticInvocation:		isAutomaticInvocation:
	description: >		description: >
	@@ -65,32 +81,22 @@ definitions:
	type: boolean		type: boolean
	instantiationLevelId:		instantiationLevelId:
	description: >		description: >
	If operation=INSTANTIATE, the identifier of the instantiation level		If operation=INSTANTIATE, the identifier of the instantiation level may be provided as an
	may be provided as an alternative way to define the resources to be		alternative way to define the resources to be added. This attribute shall only be used if
	added. This attribute shall only be used if operation=INSTANTIATE.		operation=INSTANTIATE. See note 2.
	$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"
	addResources:		addResources:
	description: >		description: >
	List of resource definitions in the VNFD for resources to be added		List of resource definitions in the VNFD for resources to be added by the LCM operation
	by the LCM operation which is related to this grant request, with		which is related to this grant request, with one entry per resource. See note 2.
	one entry per resource.
	If the granting request is for InstantiateVNF, either
	instantiationLevel or addResources shall be present.
	type: array		type: array
	items:		items:
	$ref: "#/definitions/ResourceDefinition"		$ref: "#/definitions/ResourceDefinition"
	tempResources:		tempResources:
	description: >		description: >
	List of resource definitions in the VNFD for resources to be		List of resource definitions in the VNFD for resources to be temporarily instantiated during
	temporarily instantiated during the runtime of the LCM operation		the runtime of the LCM operation which is related to this grant request, with one entry per
	which is related to this grant request, with one entry per		resource. See note 3.
	resource.
	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.
	type: array		type: array
	items:		items:
	$ref: "#/definitions/ResourceDefinition"		$ref: "#/definitions/ResourceDefinition"
	@@ -112,28 +118,10 @@ definitions:
	$ref: "#/definitions/ResourceDefinition"		$ref: "#/definitions/ResourceDefinition"
	placementConstraints:		placementConstraints:
	description: >		description: >
	Placement constraints that the VNFM may send to the NFVO in order to		Placement constraints that the VNFM may send to the NFVO in order to influence the resource
	influence the resource placement decision. If sent, the NFVO shall		placement decision. If sent, the NFVO shall take the constraints into consideration when making
	take the constraints into consideration when making resource		resource placement decisions and shall reject the grant if they cannot be honoured. See notes 4,
	placement decisions, and shall reject the grant if they cannot be		5 and 6.
	honoured.
	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.
	If fallbackBestEffort is present in placement constraints and set
	to “true”, the NFVO shall process the Affinity/AntiAffinity constraint
	in a best effort manner, in which case, if specified resources cannot be
	allocated based on specified placement constraint, the NFVO looks for an
	alternate best effort placement for the specified resources to be granted.
	In the best effort anti-affinity case, the resources are expected to be
	spread optimally over all available instances of scope (e.g. zones),
	and in the best effort affinity case, they are expected to be distributed
	optimally over fewer possible instances of scope.
	type: array		type: array
	items:		items:
	$ref: "#/definitions/PlacementConstraint"		$ref: "#/definitions/PlacementConstraint"
	@@ -230,37 +218,27 @@ definitions:
	$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"
	vnfInstanceId:		vnfInstanceId:
	description: >		description: >
	Identifier of the related VNF instance.		Identifier of the related VNF instance. See note 6.
	The NFVO shall set the value of the attribute by copying the value
	from the associated GrantRequest.
	$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"
	vnfLcmOpOccId:		vnfLcmOpOccId:
	description: >		description: >
	Identifier of the related VNF lifecycle management operation		Identifier of the related VNF lifecycle management operation occurrence.
	occurrence.		See note 6.
	The NFVO shall set the value of the attribute by copying the value
	from the associated GrantRequest.
	$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"
	vimConnectionInfo:		vimConnectionInfo:
	description: >		description: >
	Provides information regarding VIM connections that are approved to		Provides information regarding VIM connections that are approved to be used
	be used by the VNFM to allocate resources, and provides parameters		by the VNFM to allocate resources and provides parameters of these VIM connections.
	of these VIM connections.
	The VNFM shall update the " vimConnectionInfo" attribute of the		The VNFM shall update the "vimConnectionInfo" attribute of the "VnfInstance" structure
	"VnfInstance" structure by adding unknown entries received in this		by adding unknown entries received in this attribute.
	attribute.
	This attribute is not intended for the modification of vimConnectionInfo		This attribute is not intended for the modification of VimConnectionInfo entries passed
	entries passed earlier; for that, the VnfInfoModificationRequest		earlier; for that, the VnfInfoModificationRequest structure shall be used.
	structure shall be used.
	This attribute shall only be supported when VNF-related Resource		This attribute shall only be supported when VNF-related Resource Management in direct mode
	Management in direct mode is applicable. In direct mode, this		is applicable. In direct mode, this parameter shall be absent if the VIM information was
	parameter shall be absent if the VIM information was configured to		configured to the VNFM in another way, present otherwise. See note 1.
	the VNFM in another way, present otherwise.
	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.
	type: object		type: object
	additionalProperties:		additionalProperties:
	$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/VimConnectionInfo"		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/VimConnectionInfo"
	@@ -321,25 +299,8 @@ definitions:
	$ref: "#/definitions/GrantInfo"		$ref: "#/definitions/GrantInfo"
	vimAssets:		vimAssets:
	description: >		description: >
	Information about assets for the VNF that are managed by the NFVO		Information about assets for the VNF that are managed by the NFVO in the VIM,
	in the VIM, such as software images and virtualised compute resource		such as software images and virtualised compute resource flavours. See note 3.
	flavours.
	The Grant response allows the NFVO to pass to the VNFM VIM assets
	related to the VNF package that is identified by the vnfdId attribute
	in the corresponding Grant request. The NFVO may send in each Grant
	response the full set of VIM assets related to the VNF package defined
	by the vnfdId in the related Grant request, but shall send this information
	if the vnfdId in the related Grant request differs from the vnfdId passed
	in the previous Grant request, or if the Grant response is related to an
	InstantiateVnf operation.
	The set of VIM assets shall not change between subsequent Grant responses
	if the vnfdId has not changed. During each LCM operation occurrence,
	the VIM assets that relate to the VNF package identified by the current value
	of the vnfdId attribute in the “VnfInstance” structure shall be used by the
	VNFM for newly created resources. If the VNF package identifier of the
	VNF instance has been updated, VIM assets that relate to the previously-used
	VNF package(s), and that were communicated in previous Grant responses,
	apply to existing resources.
	type: object		type: object
	properties:		properties:
	computeResourceFlavours:		computeResourceFlavours:
	@@ -365,70 +326,15 @@ definitions:
	$ref: "#/definitions/VimSnapshotResource"		$ref: "#/definitions/VimSnapshotResource"
	extVirtualLinks:		extVirtualLinks:
	description: >		description: >
	Information about external VLs to connect the VNF to.		Information about external VLs to connect the VNF to. See notes 5 and 7. If this attribute
	For any VNF lifecycle management operation request that allows to pass		is present according to note 5 or note 7, it need not contain those entries that are unchanged
	"extVirtualLinks" and/or "extManagedVirtualLinks" parameters, such as		compared to the entries that were passed in the LCM operation which is related to this granting exchange.
	InstantiateVnf, ChangeVnfFlavour, ChangeExtVnfConnectivity or
	ChangeCurrentVnfPackage, the NFVO may provide the "extVirtualLinks"
	and/or "extManagedVirtualLinks" attributes in the Grant to override
	the values passed in these parameters previously in the associated
	VNF lifecycle management request, if the lifecycle management
	request has originated from the NFVO itself. The NFVO shall
	not provide the "extVirtualLinks" and/or "extManagedVirtualLinks"
	attributes in the Grant otherwise.
	In case of granting an InstantiateVnf request that has originated from the NFVO
	and that did not contain the "extVirtualLinks" attribute, this attribute shall be
	set by the NFVO. Further in case of granting an InstantiateVnf request that has
	originated from the NFVO and that did not contain the "extManagedVirtualLinks"
	attribute, this attribute shall be set by the NFVO if there is the need to provide
	information about externally-managed virtual links.

	If this attribute is present , it need not contain
	those entries that are unchanged compared to the entries that were passed
	in the LCM operation which is related to this granting exchange.
	External and/or externally-managed internal VLs can be passed in VNF
	lifecycle management operation requests such as InstantiateVnf, ChangeVnfFlavor,
	ChangeExtVnfConnectivity or ChangeCurrentVnfPackage 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.
	In case of granting an InstantiateVnf request that has originated from the NFVO
	and that did not contain the "extVirtualLinks" attribute, this attribute shall be
	set by the NFVO. Further in case of granting an InstantiateVnf request that has
	originated from the NFVO and that did not contain the "extManagedVirtualLinks"
	attribute, this attribute shall be set by the NFVO if there is the need to provide
	information about externally-managed virtual links.
	type: array		type: array
	items:		items:
	$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/ExtVirtualLinkData"		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/ExtVirtualLinkData"
	extManagedVirtualLinks:		extManagedVirtualLinks:
	description: >		description: >
	Information about internal VLs that are managed by other entities		Information about internal VLs that are managed by other entities than the VNFM. See notes 4, 5 and 7.
	than the VNFM.
	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.
	For any VNF lifecycle management operation request that allows to pass
	"extVirtualLinks" and/or "extManagedVirtualLinks" parameters, such as
	InstantiateVnf, ChangeVnfFlavour, ChangeExtVnfConnectivity or
	ChangeCurrentVnfPackage, the NFVO may provide the "extVirtualLinks"
	and/or "extManagedVirtualLinks" attributes in the Grant to override
	the values passed in these parameters previously in the associated
	VNF lifecycle management request, if the lifecycle management
	request has originated from the NFVO itself. The NFVO shall
	not provide the "extVirtualLinks" and/or "extManagedVirtualLinks"
	attributes in the Grant otherwise.
	In case of granting an InstantiateVnf request that has originated from the NFVO
	and that did not contain the "extVirtualLinks" attribute, this attribute shall be
	set by the NFVO. Further in case of granting an InstantiateVnf request that has
	originated from the NFVO and that did not contain the "extManagedVirtualLinks"
	attribute, this attribute shall be set by the NFVO if there is the need to provide
	information about externally-managed virtual links.
	type: array		type: array
	items:		items:
	$ref: "../../VNFLifecycleManagement/definitions/SOL003VNFLifecycleManagement_def.yaml#/definitions/ExtManagedVirtualLinkData"		$ref: "../../VNFLifecycleManagement/definitions/SOL003VNFLifecycleManagement_def.yaml#/definitions/ExtManagedVirtualLinkData"
	@@ -461,8 +367,11 @@ definitions:

	ResourceDefinition:		ResourceDefinition:
	description: >		description: >
	This type provides information of an existing or proposed resource used		This type provides information of an existing or proposed resource used by the VNF.
	by the VNF.		It shall comply with the provisions defined in table 9.5.3.2-1.

			NOTE: The use cases UC#4 and UC#5 in Annex A.4 of ETSI GS NFV-IFA 007 provide examples
			for such a configuration.
	type: object		type: object
	required:		required:
	- id		- id
	@@ -511,15 +420,11 @@ definitions:
	secondaryResourceTemplateId:		secondaryResourceTemplateId:
	description: >		description: >
	Reference to a secondary resource template (VnfExtCpd) in the VNFD.		Reference to a secondary resource template (VnfExtCpd) in the VNFD.
	Shall be present if type="LINKPORT" and the linkport is shared by two external		Shall be present if type="LINKPORT" and the linkport is shared by two external CP instances,
	CP instances, one exposing a VNFC CP instance (based on a VnfExtCpd referenced		one exposing a VNFC CP instance (based on a VnfExtCpd referenced by "resourceTemplateId") and
	by "resourceTemplateId") and another one exposing a VIP CP instance (based on a		another one exposing a VIP CP instance (based on a VnfExtCpd referenced by this attribute).
	VnfExtCpd referenced by this attribute). Shall be absent otherwise.		Shall be absent otherwise. See note.

	The use cases UC#4 and UC#5 in Annex A.4 of ETSI GS NFV-IFA 007 [1] provide examples for such a configuration.

	$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnfd"		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnfd"

	resource:		resource:
	description: >		description: >
	Resource information for an existing resource. Shall be present for		Resource information for an existing resource. Shall be present for
	@@ -878,6 +783,19 @@ definitions:
	SnapshotResourceDefinition:		SnapshotResourceDefinition:
	description: >		description: >
	This type represents resource definition information related to a snapshot resource.		This type represents resource definition information related to a snapshot resource.
			It shall comply with the provisions defined in table 9.5.3.11-1.

			NOTE 1: If present, the value of the "vduId" (for a related VDU) in the "VnfcResourceInfo"
			referred by the "vnfcInfoId" of the "VnfcSnapshotInfo" shall match the value of the
			"vduId" in the resource definition that is signalled in the granting request.
			NOTE 2: For snapshot resource definitions extracted from a VNF snapshot package, only the
			"vnfcSnapshotId" and "storageSnapshotId" (in case of a storage type of resource)
			are applicable. If the snapshot resource definition is generated as part of a VNF
			snapshot created by the VNFM (that is, not extracted from a VNF snapshot package),
			the "snapshotResource" is applicable. This is a similar specification as the one
			defined with the "vduId", "resourceTemplateId" and "resource" attributes provided in
			the ResourceDefinition, but in this case applicable to resources that are defined from
			VNF snapshots instead of VNFD.
	type: object		type: object
	required:		required:
	- vnfSnapshotId		- vnfSnapshotId
	@@ -890,53 +808,25 @@ definitions:
	$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"
	vnfcSnapshotId:		vnfcSnapshotId:
	description: >		description: >
	Reference to the information about a specific VNFC snapshot (refer to "VnfcSnapshotInfo")		Reference to the information about a specific VNFC snapshot (refer to "VnfcSnapshotInfo") of
	of the VNF snapshot. The identifier is unique within the scope of a VNF snapshot, identified		the VNF snapshot. The identifier is unique within the scope of a VNF snapshot, identified by
	by the "vnfSnapshotId" attribute. Shall only be present if the operation to be granted		the "vnfSnapshotId" attribute. Shall only be present if the operation to be granted concerns
	concerns to reverting the VNF to a VNF snapshot, and the resource is planned to be added		to reverting the VNF to a VNF snapshot, and the resource is planned to be added based on the
	based on the VNFC snapshot, and the type of resource is "COMPUTE" or "STORAGE".		VNFC snapshot, and the type of resource is "COMPUTE" or "STORAGE". See notes 1 and 2.

	If present, the value of the "vduId" (for a related VDU) in the "VnfcResourceInfo" referred
	by the "vnfcInfoId" of the "VnfcSnapshotInfo" shall match the value of the "vduId" in the
	resource definition that is signalled in the granting request.

	For snapshot resource definitions extracted from a VNF snapshot package, only the
	"vnfcSnapshotId" and "storageSnapshotId" (in case of a storage type of resource) are applicable.
	If the snapshot resource definition is generated as part of a VNF snapshot created by the VNFM
	(that is, not extracted from a VNF snapshot package), the "snapshotResource" is applicable.
	This is a similar specification as the one defined with the "vduId", "resourceTemplateId" and
	"resource" attributes provided in the ResourceDefinition, but in this case applicable to resources
	that are defined from VNF snapshots instead of VNFD.
	$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierLocal"		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierLocal"
	storageSnapshotId:		storageSnapshotId:
	description: >		description: >
	Reference to a snapshotted storage resource associated to the VNFC snapshot. Shall only be		Reference to a snapshotted storage resource associated to the VNFC snapshot. Shall only be present
	present if the operation to be granted concerns to reverting the VNF to a VNF snapshot,		if the operation to be granted concerns to reverting the VNF to a VNF snapshot, and the storage
	and the storage resource is planned to be added based on the VNFC snapshot, and the type		resource is planned to be added based on the VNFC snapshot, and the type of resource is "STORAGE".
	of resource is "STORAGE".		See note 2.

	For snapshot resource definitions extracted from a VNF snapshot package, only the
	"vnfcSnapshotId" and "storageSnapshotId" (in case of a storage type of resource) are applicable.
	If the snapshot resource definition is generated as part of a VNF snapshot created by the VNFM
	(that is, not extracted from a VNF snapshot package), the "snapshotResource" is applicable.
	This is a similar specification as the one defined with the "vduId", "resourceTemplateId" and
	"resource" attributes provided in the ResourceDefinition, but in this case applicable to resources
	that are defined from VNF snapshots instead of VNFD.
	$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnf"		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnf"
	snapshotResource:		snapshotResource:
	description: >		description: >
	Resource information for an existing snapshot resource. Shall only be present if the		Resource information for an existing snapshot resource. Shall only be present if the operation to
	operation to be granted concerns to reverting the VNF to a VNF snapshot and the resource is		be granted concerns to reverting the VNF to a VNF snapshot and the resource is planned to be added
	planned to be added based on an existing VNF snapshot that has been created by the VNFM.		based on an existing VNF snapshot that has been created by the VNFM. Shall be absent otherwise.
	Shall be absent otherwise.		See note 2.

	For snapshot resource definitions extracted from a VNF snapshot package, only the
	"vnfcSnapshotId" and "storageSnapshotId" (in case of a storage type of resource) are applicable.
	If the snapshot resource definition is generated as part of a VNF snapshot created by the VNFM
	(that is, not extracted from a VNF snapshot package), the "snapshotResource" is applicable.
	This is a similar specification as the one defined with the "vduId", "resourceTemplateId" and
	"resource" attributes provided in the ResourceDefinition, but in this case applicable to resources
	that are defined from VNF snapshots instead of VNFD.
	$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/ResourceHandle"		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/ResourceHandle"

	VimSnapshotResource:		VimSnapshotResource:

src/SOL003/VNFPackageManagement/definitions/SOL003VNFPackageManagement_def.yaml

+35 −42

File changed.

Preview size limit exceeded, changes collapsed.

src/SOL003/VNFSnapshotPackageManagement/definitions/SOL003VNFSnapshotPackageManagement_def.yaml

+20 −26

File changed.

Preview size limit exceeded, changes collapsed.

src/definitions/SOL002SOL003VNFFaultManagement_def.yaml

+15 −14

File changed.

Preview size limit exceeded, changes collapsed.

Admin message