Merge branch '3.5.1-dev' of https://forge.etsi.org/gitlab/nfv/SOL002-SOL003 into 3.5.1-dev (18886948) · Commits · NFV - Network Functions Virtualisation / SOL002-SOL003

src/SOL003/VNFLifecycleManagement/definitions/SOL003VNFLifecycleManagement_def.yaml

+346 −379

File changed.

Preview size limit exceeded, changes collapsed.

src/SOL003/VNFLifecycleOperationGranting/definitions/SOL003VNFLifecycleOperationGranting_def.yaml

+89 −199

Changes for src/SOL003/VNFLifecycleOperationGranting/definitions/SOL003VNFLifecycleOperationGranting_def.yaml: 89 added lines, 199 removed lines.
Original line number	Diff line number	Diff line
		@@ -4,7 +4,26 @@
		definitions:
		GrantRequest:
		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
		required:
		- vnfInstanceId
		@@ -50,10 +69,7 @@ definitions:
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"
		operation:
		description: >
		The lifecycle management operation for which granting is requested.
		The VNF LCM operations CreateVnfIdentifier, DeleteVnfIdentifier,
		QueryVnf and ModifyVnfInformation can be executed by the VNFM
		without requesting granting.
		The lifecycle management operation for which granting is requested. See note 1.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/GrantedLcmOperationType"
		isAutomaticInvocation:
		description: >
		@@ -65,32 +81,22 @@ definitions:
		type: boolean
		instantiationLevelId:
		description: >
		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.
		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.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"
		addResources:
		description: >
		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.
		If the granting request is for InstantiateVNF, either
		instantiationLevel or addResources shall be present.
		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.
		type: array
		items:
		$ref: "#/definitions/ResourceDefinition"
		tempResources:
		description: >
		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.
		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.
		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.
		type: array
		items:
		$ref: "#/definitions/ResourceDefinition"
		@@ -112,28 +118,10 @@ definitions:
		$ref: "#/definitions/ResourceDefinition"
		placementConstraints:
		description: >
		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.
		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.
		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 notes 4,
		5 and 6.
		type: array
		items:
		$ref: "#/definitions/PlacementConstraint"
		@@ -230,37 +218,27 @@ definitions:
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"
		vnfInstanceId:
		description: >
		Identifier of the related VNF instance.
		The NFVO shall set the value of the attribute by copying the value
		from the associated GrantRequest.
		Identifier of the related VNF instance. See note 6.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"
		vnfLcmOpOccId:
		description: >
		Identifier of the related VNF lifecycle management operation
		occurrence.
		The NFVO shall set the value of the attribute by copying the value
		from the associated GrantRequest.
		Identifier of the related VNF lifecycle management operation occurrence.
		See note 6.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"
		vimConnectionInfo:
		description: >
		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 vimConnectionInfo
		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.
		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.
		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 VimConnectionInfo 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.
		type: object
		additionalProperties:
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/VimConnectionInfo"
		@@ -321,25 +299,8 @@ definitions:
		$ref: "#/definitions/GrantInfo"
		vimAssets:
		description: >
		Information about assets for the VNF that are managed by the NFVO
		in the VIM, such as software images and virtualised compute resource
		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.
		Information about assets for the VNF that are managed by the NFVO in the VIM,
		such as software images and virtualised compute resource flavours. See note 3.
		type: object
		properties:
		computeResourceFlavours:
		@@ -365,70 +326,15 @@ definitions:
		$ref: "#/definitions/VimSnapshotResource"
		extVirtualLinks:
		description: >
		Information about external VLs to connect the VNF to.
		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.

		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.
		Information about external VLs to connect the VNF to. See notes 5 and 7. If this attribute
		is present according to note 5 or note 7, 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.
		type: array
		items:
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/ExtVirtualLinkData"
		extManagedVirtualLinks:
		description: >
		Information about internal VLs that are managed by other entities
		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.
		Information about internal VLs that are managed by other entities than the VNFM. See notes 4, 5 and 7.
		type: array
		items:
		$ref: "../../VNFLifecycleManagement/definitions/SOL003VNFLifecycleManagement_def.yaml#/definitions/ExtManagedVirtualLinkData"
		@@ -461,8 +367,11 @@ definitions:

		ResourceDefinition:
		description: >
		This type provides information of an existing or proposed resource used
		by the VNF.
		This type provides information of an existing or proposed resource used 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
		required:
		- id
		@@ -511,15 +420,11 @@ definitions:
		secondaryResourceTemplateId:
		description: >
		Reference to a secondary resource template (VnfExtCpd) in the VNFD.
		Shall be present if type="LINKPORT" and the linkport is shared by two external
		CP instances, one exposing a VNFC CP instance (based on a VnfExtCpd referenced
		by "resourceTemplateId") and another one exposing a VIP CP instance (based on a
		VnfExtCpd referenced by this attribute). Shall be absent otherwise.

		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.

		Shall be present if type="LINKPORT" and the linkport is shared by two external CP instances,
		one exposing a VNFC CP instance (based on a VnfExtCpd referenced by "resourceTemplateId") and
		another one exposing a VIP CP instance (based on a VnfExtCpd referenced by this attribute).
		Shall be absent otherwise. See note.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnfd"

		resource:
		description: >
		Resource information for an existing resource. Shall be present for
		@@ -878,6 +783,19 @@ definitions:
		SnapshotResourceDefinition:
		description: >
		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
		required:
		- vnfSnapshotId
		@@ -890,53 +808,25 @@ definitions:
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"
		vnfcSnapshotId:
		description: >
		Reference to the information about a specific VNFC snapshot (refer to "VnfcSnapshotInfo")
		of the VNF snapshot. The identifier is unique within the scope of a VNF snapshot, identified
		by the "vnfSnapshotId" attribute. Shall only be present if the operation to be granted
		concerns to reverting the VNF to a VNF snapshot, and the resource is planned to be added
		based on the VNFC snapshot, and the type of resource is "COMPUTE" or "STORAGE".

		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.
		Reference to the information about a specific VNFC snapshot (refer to "VnfcSnapshotInfo") of
		the VNF snapshot. The identifier is unique within the scope of a VNF snapshot, identified by
		the "vnfSnapshotId" attribute. Shall only be present if the operation to be granted concerns
		to reverting the VNF to a VNF snapshot, and the resource is planned to be added based on the
		VNFC snapshot, and the type of resource is "COMPUTE" or "STORAGE". See notes 1 and 2.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierLocal"
		storageSnapshotId:
		description: >
		Reference to a snapshotted storage resource associated to the VNFC snapshot. Shall only be
		present if the operation to be granted concerns to reverting the VNF to a VNF snapshot,
		and the storage resource is planned to be added based on the VNFC snapshot, and the type
		of resource is "STORAGE".

		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.
		Reference to a snapshotted storage resource associated to the VNFC snapshot. Shall only be present
		if the operation to be granted concerns to reverting the VNF to a VNF snapshot, and the storage
		resource is planned to be added based on the VNFC snapshot, and the type of resource is "STORAGE".
		See note 2.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnf"
		snapshotResource:
		description: >
		Resource information for an existing snapshot resource. Shall only be present if the
		operation to be granted concerns to reverting the VNF to a VNF snapshot and the resource is
		planned to be added based on an existing VNF snapshot that has been created by the VNFM.
		Shall be absent otherwise.

		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.
		Resource information for an existing snapshot resource. Shall only be present if the operation to
		be granted concerns to reverting the VNF to a VNF snapshot and the resource is planned to be added
		based on an existing VNF snapshot that has been created by the VNFM. Shall be absent otherwise.
		See note 2.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/ResourceHandle"

		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

+14 −13

File changed.

Preview size limit exceeded, changes collapsed.