add and update attributes in VNF LC operating granting API in SOL003 (ccf6c8f5) · Commits · NFV - Network Functions Virtualisation / SOL002-SOL003

src/SOL003/VNFLifecycleOperationGranting/definitions/SOL003VNFLifecycleOperationGranting_def.yaml

+205 −60

Original line number	Diff line number	Diff line
		@@ -6,30 +6,36 @@ definitions:
		description: >
		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: For the affinity/anti-affinity rules defined in the VNFD and the placement constraints in the GrantVnfLifecycleOperation
		as defined in this clause, the following applies: Assuming unlimited capacity, the combination of all the
		aforementioned rules shall be satisfiable by at least one possible placement of the new resources, with the
		exception that some of the rules with fallbackBestEffort may be unsatisfiable due to the actual placement of
		existing resources. In this case, rules with fallbackBestEffort are allowed to be violated only in relation
		to the placement of existing resources.
		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 and set to "true" in one or more placement constraints and, the NFVO
		cannot find a resource placement that satisfies all of these due to limited capacity, the NFVO shall process
		each such affinity/anti-affinity constraint in a best effort manner, in which case, if specified resources
		cannot be allocated based on the specified placement constraint, the NFVO shall look 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 as few instances of scope as
		possible. Being able to satisfy a "best-effort" constraint in a best effort manner only, as defined above,
		shall not lead to rejecting the grant.
		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, only one of the three parameters (instantiationLevel or
		targetScaleLevelInfo 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: For the affinity/anti-affinity rules defined in the VNFD and the placement constraints in the
		GrantVnfLifecycleOperation as defined in this clause, the following applies: Assuming unlimited
		capacity, the combination of all the aforementioned rules shall be satisfiable by at least one possible
		placement of the new resources, with the exception that some of the rules with fallbackBestEffort
		may be unsatisfiable due to the actual placement of existing resources. In this case, rules with
		fallbackBestEffort are allowed to be violated only in relation to the placement of existing resources.
		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 and set to "true" in one or more placement constraints and the NFVO
		cannot find a resource placement that satisfies all of these due to limited capacity, the NFVO shall
		process each such affinity/antiAffinity constraint in a best effort manner, in which case, if specified
		resources cannot be allocated based on the specified placement constraint, the NFVO shal look for
		an alternate best effort placement for the specified resources to be granted. In the best effort antiaffinity 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 as
		few instances of scope as possible. Being able to satisfy a "best-effort" constraint in a best effort
		manner only, as defined above, shall not lead to rejecting the grant.
		NOTE 7: The target size for VNF instantiation may be specified in either instantiationLevelId or
		targetScaleLevelInfo, but not both.
		NOTE 8: If targetScaleLevelInfo is specified, information provided in targetScaleLevelInfo shall be used for
		scalable constituents of the VNF (e.g, VDUs/VLs) in the granting process. For scaling aspects not
		specified in targetScaleLevelInfo or for the VNF constituents (e.g.,VDUs/VLs) that are not scalable,
		the default instantiation level as declared in the VNFD shall be used in the granting process.
		type: object
		required:
		- vnfInstanceId
		@@ -89,8 +95,23 @@ definitions:
		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. See note 2.
		operation=INSTANTIATE. See notes 2 and 7.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"
		targetScaleLevelInfo:
		description: >
		This attribute shall only be used for
		Instantiate VNF requests. This is applicable
		if VNF supports target scale level
		instantiation.
		This attribute provides an alternative way to
		define the resources to be added for the
		VNFs.
		For each scaling aspect of the current
		deployment flavour, the attribute specifies
		the scale level of VNF constituents (e.g.,
		VDU level) to be instantiated. See notes 2,
		7 and 8.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/ScaleInfo"
		addResources:
		description: >
		List of resource definitions in the VNFD for resources to be added by the LCM operation
		@@ -243,18 +264,50 @@ definitions:
		$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. See note 1.
		Provides information regarding VIM and/or CISM connections that are
		approved to be used by the VNFM to allocate resources and provides
		parameters of these VIM and/or CISM 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
		- all or part of the granted
		resources are managed by
		a VIM and VNF-related
		Resource Management in
		direct mode is applicable.
		- all or part of the granted
		resources are managed by
		a CISM.
		In direct mode, this parameter shall
		be absent if the VIM or CISM
		information was configured to the
		VNFM in another way, present
		otherwise.
		See note 1.
		type: object
		additionalProperties:
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/VimConnectionInfo"
		cirConnectionInfo:
		description: >
		Provides information regarding a CIR connection that is approved to be
		used by the VNFM to obtain information about OS container
		images. It shall be absent in case of rejection or if the CIR information
		was configured to the VNFM in another way or if the granted
		resources are not managed by a CISM, present otherwise.
		type: object
		additionalProperties:
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/VimConnectionInfo"
		mciopRepositoryInfo:
		description: >
		Provides information regarding a MCIOP repository. It shall be absent
		in case of rejection or if the MCIOP repository information was configured
		to the VNFM in another way or if the granted resources are not managed
		by a CISM, present otherwise.
		type: object
		additionalProperties:
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/VimConnectionInfo"
		@@ -315,8 +368,10 @@ 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. See note 3.
		Information about assets for the VNF that are defined in VNFD and
		managed by the NFVO in the VIM/NFVI, such as software images
		and virtualised compute resource flavours.
		See note 3.
		type: object
		properties:
		computeResourceFlavours:
		@@ -340,6 +395,13 @@ definitions:
		type: array
		items:
		$ref: "#/definitions/VimSnapshotResource"
		storageAssets:
		description: >
		Mappings between virtual storages defined in the VNFD and virtual
		storages managed in the NFVI.
		type: array
		items:
		$ref: "#/definitions/StorageAsset"
		extVirtualLinks:
		description: >
		Information about external VLs to connect the VNF to. See notes 5, 7 and 8. If this attribute
		@@ -418,6 +480,8 @@ definitions:
		- VL
		- STORAGE
		- LINKPORT
		- OSCONTAINER
		- VIRTUALCP
		vduId:
		description: >
		Reference to the related VDU in the VNFD applicable to this
		@@ -437,6 +501,12 @@ definitions:
		- if type="COMPUTE": VirtualComputeDesc
		- if type="LINKPORT" : VnfExtCpd
		- if type="STORAGE" : VirtualStorageDesc
		- If type="OSCONTAINER": OsContainerDesc
		- Cardinality may be greater than "1" when type="OSCONTAINER" and multiple references to
		OsContainerDesc are present in the VDU indicated by the "vduId". Cardinality shall be "1" otherwise.
		type: array
		minItems: 1
		items:
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnfd"
		secondaryResourceTemplateId:
		description: >
		@@ -480,14 +550,16 @@ definitions:
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVim"
		vimConnectionId:
		description: >
		Identifier of the VIM connection to be used to manage this resource.
		Identifier of the VIM or CISM connection to be used to manage this resource.
		Shall be present for new resources, and shall be absent for
		resources that have already been allocated.
		The applicable "VimConnectionInfo" structure, which is referenced by
		vimConnectionId, can be obtained from the "vimConnectionInfo"
		attribute of the "VnfInstance" structure.
		This attribute shall only be supported when VNF-related Resource
		Management in direct mode is applicable.
		This attribute shall only be supported when
		- all or part of the granted resources are managed by a VIM and VNF-related Resource Management in
		direct mode is applicable.
		- all or part of the granted resources are managed by a CISM.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"
		resourceProviderId:
		description: >
		@@ -520,7 +592,24 @@ definitions:
		This attribute shall be absent for resources that have already been
		allocated.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVim"

		containerNamespace:
		description: >
		The value of the namespace in which the MCIOs of a VNF with containerized components shall be deployed.
		This attribute shall be present if the granted resources are managed by a CISM. The attribute shall be
		absent if the granted resources are not managed by a CISM.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/String"
		mcioConstraints:
		description: >
		The constraint values to be assigned to MCIOs of a VNF with containerized components.
		The key in the key-value pair indicates the parameter name of
		the MCIO constraint in the MCIO declarative descriptor and
		shall be one of the possible enumeration values of the
		"mcioConstraintsParams" attribute as specified in clause
		7.1.6.2.2 of ETSI GS NFV-IFA 011 [10]. The value in the keyvalue pair indicates the value to be assigned
		to the MCIO constraint.
		This attribute shall be present if the granted resources are managed by a CISM. The attribute shall be
		absent if the granted resources are not managed by a CISM.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/KeyValuePairs"
		ZoneInfo:
		description: >
		This type provides information regarding a resource zone.
		@@ -596,6 +685,13 @@ definitions:
		zones:
		{type="AFFINITY"; scope="NFVI_POP"; {resource1,resource2}}
		{type="ANTI_AFFINITY"; scope="ZONE"; {resource1,resource2}}

		Annex B in ETSI GS NFV-IFA 011 [10] provides additional description and examples about the usage of the
		affinity/anti-affinity rules.


		NOTE: The "CIS_NODE" and “CONTAINER_NAMESPACE” scopes shall only be used to express affinity or
		antiaffinity relationship between containerized workloads.
		type: object
		required:
		- affinityOrAntiAffinity
		@@ -617,16 +713,21 @@ definitions:
		The scope of the placement constraint indicating the category of the
		"place" where the constraint applies.
		Permitted values:
		* NFVI_POP
		* ZONE
		* ZONE_GROUP
		* NFVI_NODE
		- NFVI_POP
		- ZONE
		- ZONE_GROUP
		- NFVI_NODE
		- CIS_NODE
		- CONTAINER_NAMESPACE
		- See note.
		type: string
		enum:
		- NFVI_POP
		- ZONE
		- ZONE_GROUP
		- NFVI_NODE
		- CIS_NODE
		- CONTAINER_NAMESPACE
		resource:
		description: >
		References to resources in the constraint rule.
		@@ -767,7 +868,10 @@ definitions:
		description: >
		This type contains a mapping between a software image definition the
		VNFD and the corresponding software image managed by the NFVO in the
		VIM which is needed during compute resource instantiation.
		VIM or CIR which is needed during compute resource instantiation.

		NOTE: For an OS container image, the value of this attribute is a string concatenating the name and tag of the
		image in the CIR separated by a colon ':' with no spaces, e.g. “dbImage:001”.
		type: object
		required:
		- vnfdSoftwareImageId
		@@ -775,13 +879,15 @@ definitions:
		properties:
		vimConnectionId:
		description: >
		Identifier of the VIM connection to access the software image
		referenced in this structure.
		The applicable "VimConnectionInfo" structure, which is referenced by
		vimConnectionId, can be obtained from the "vimConnectionInfo"
		attribute of the "VnfInstance" structure.
		This attribute shall only be supported and present if VNF-related
		resource management in direct mode is applicable.
		Identifier of the VIM or CIR connection to access the
		software image referenced in this structure.
		The applicable "VimConnectionInfo" structure, which is
		referenced by vimConnectionId, can be obtained from the
		"vimConnectionInfo" attribute of the "VnfInstance" structure.
		This attribute shall only be supported and present if
		- the software image is to be loaded in a virtual machine and VNF-related resource management in
		direct mode is applicable.
		- the software image is to be loaded in an OS container managed by a CISM.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"
		resourceProviderId:
		description: >
		@@ -799,7 +905,7 @@ definitions:
		vimSoftwareImageId:
		description: >
		Identifier of the software image in the resource management layer
		(i.e. VIM).
		(i.e. VIM). See note.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVim"

		SnapshotResourceDefinition:
		@@ -897,3 +1003,42 @@ definitions:
		description: >
		Identifier of the snapshot resource in the resource management layer (i.e. VIM).
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVim"

		StorageAsset:
		description: >
		This type provides a mapping between a VirtualStorageDesc in the VNFD and the corresponding virtual storage
		managed by the NFVO in the NFVI. It shall comply with the provisions defined in table 9.5.3.13-1.
		type: object
		required:
		- virtualStorageDescId
		- storageClassName
		properties:
		vimConnectionId:
		description: >
		Identifier of the VIM or CISM connection to access the virtual
		storage referenced in this data type.
		The applicable "VimConnectionInfo" structure, which is referenced by
		vimConnectionId, can be obtained from the "vimConnectionInfo"
		attribute of the "VnfInstance" structure.
		This attribute shall only be supported and present if
		- all or part of the granted resources are managed by
		a VIM and VNF related resource management in direct mode is applicable.
		- all or part of the granted resources are managed by a CISM.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"
		resourceProviderId:
		description: >
		Identifier used by NFVO to determine the entity responsible for the
		management of the storage asset.
		This attribute shall only be supported and present if VNF-related resource
		management in indirect mode is applicable. The identification scheme
		is outside the scope of the present document.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier"
		virtualStorageDescId:
		description: >
		Identifier of the virtual storage descriptor in the VNFD.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnfd"
		storageClassName:
		description: >
		Name of storage class, which represents features and policies
		concerning a virtual storage.
		$ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/String"