From af28be2142ba6ba825b6429929c7749acb01e4e9 Mon Sep 17 00:00:00 2001 From: Francesca Moscatelli Date: Wed, 5 May 2021 13:04:04 +0200 Subject: [PATCH] SOL003: added notes to data types main descriptions --- .../SOL003VNFLifecycleManagement_def.yaml | 755 +++++++++--------- ...L003VNFLifecycleOperationGranting_def.yaml | 290 +++---- .../SOL003VNFPackageManagement_def.yaml | 77 +- ...OL003VNFSnapshotPackageManagement_def.yaml | 46 +- .../SOL002SOL003VNFFaultManagement_def.yaml | 29 +- .../SOL002SOL003VNFIndicator_def.yaml | 56 +- ...OL002SOL003VNFLifecycleManagement_def.yaml | 336 ++++---- ...002SOL003VNFPerformanceManagement_def.yaml | 159 ++-- 8 files changed, 775 insertions(+), 973 deletions(-) diff --git a/src/SOL003/VNFLifecycleManagement/definitions/SOL003VNFLifecycleManagement_def.yaml b/src/SOL003/VNFLifecycleManagement/definitions/SOL003VNFLifecycleManagement_def.yaml index 50103c4a..f6db8575 100644 --- a/src/SOL003/VNFLifecycleManagement/definitions/SOL003VNFLifecycleManagement_def.yaml +++ b/src/SOL003/VNFLifecycleManagement/definitions/SOL003VNFLifecycleManagement_def.yaml @@ -3,7 +3,21 @@ definitions: InstantiateVnfRequest: - #SOL003 location: 5.5.2.4 + description: > + This type represents request parameters for the "Instantiate VNF" operation. + It shall comply with the provisions defined in table 5.5.2.4-1. + + NOTE 1: 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. + NOTE 2: It is possible to have several ExtManagedVirtualLinkData for the same VNF + internal VL in case of a multi-site VNF spanning several VIMs. The set of + ExtManagedVirtualLinkData corresponding to the same VNF internal VL shall + indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed + multi-site VL instance (refer to clause 4.4.1.12). type: object required: - flavourId @@ -26,18 +40,7 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/ExtVirtualLinkData" extManagedVirtualLinks: description: > - Information about internal VLs that are managed by the NFVO. - - NOTES: - 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. - - It is possible to have several ExtManagedVirtualLinkData for the same VNF internal VL in case of a - multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkData corresponding to the same - VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed - multi-site VL instance (refer to clause 4.4.1.12). + Information about internal VLs that are managed by the NFVO. See note 1 and note 2. type: array items: $ref: "#/definitions/ExtManagedVirtualLinkData" @@ -131,9 +134,20 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier" ChangeVnfFlavourRequest: - #SOL003 location: 5.5.2.7 description: > - This type represents request parameters for the "Change VNF flavour" operation. + This type represents request parameters for the "Change VNF flavour" operation. + It shall comply with the provisions defined in table 5.5.2.7-1. + + NOTE 1: 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. + NOTE 2: It is possible to have several ExtManagedVirtualLinkData for the same VNF internal + VL in case of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkData + corresponding to the same VNF internal VL shall indicate so by referencing to the same + VnfVirtualLinkDesc and externally-managed multi-site VL instance (refer to clause 4.4.1.12). type: object required: - newFlavourId @@ -157,18 +171,7 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/ExtVirtualLinkData" extManagedVirtualLinks: description: > - Information about internal VLs that are managed by the NFVO. - - NOTES: - 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. - - It is possible to have several ExtManagedVirtualLinkData for the same VNF internal VL in case of a - multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkData corresponding to the same - VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed - multi-site VL instance (refer to clause 4.4.1.12). + Information about internal VLs that are managed by the NFVO. See notes 1 and 2. type: array items: $ref: "#/definitions/ExtManagedVirtualLinkData" @@ -202,22 +205,31 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/KeyValuePairs" TerminateVnfRequest: + description: > + This type represents request parameters for the "Terminate VNF" operation. + It shall comply with the provisions defined in table 5.5.2.8-1. + + NOTE: If the VNF is still in service, requesting forceful termination can + adversely impact network service. type: object required: - terminationType properties: terminationType: description: > - Indicates whether forceful or graceful termination is requested. + Indicates whether forceful or graceful termination is requested. + See note. + Permitted values: - * FORCEFUL: The VNFM will shut down the VNF and release the - resources immediately after accepting the request. - * GRACEFUL: The VNFM will first arrange to take the VNF out of - service after accepting the request. Once the operation of taking - the VNF out of service finishes (irrespective of whether it has - succeeded or failed) or once the timer value specified in the - "gracefulTerminationTimeout" attribute expires, the VNFM will shut - down the VNF and release the resources. + - FORCEFUL: The VNFM will shut down the VNF and release the + resources immediately after accepting the request. + - GRACEFUL: The VNFM will first arrange to take the VNF out of + service after accepting the request. Once the operation + of taking the VNF out of service finishes (irrespective + of whether it has succeeded or failed) or once the timer + value specified in the "gracefulTerminationTimeout" + attribute expires, the VNFM will shut down the VNF and + release the resources. type: string enum: - FORCEFUL @@ -256,8 +268,18 @@ definitions: OperateVnfRequest: description: > - This type represents request parameters for the "Operate VNF" operation. - type: object + This type represents request parameters for the "Operate VNF" operation. + It shall comply with the provisions defined in table 5.5.2.10-1. + + NOTE: The "stopType" and "gracefulStopTimeout" attributes shall be absent, + when the "changeStateTo" attribute is equal to "STARTED". + The "gracefulStopTimeout" attribute shall be present, when the "changeStateTo" + is equal to "STOPPED" and the "stopType" attribute is equal to "GRACEFUL". + The "gracefulStopTimeout" attribute shall be absent, when the "changeStateTo" + attribute is equal to "STOPPED" and the "stopType" attribute is equal to "FORCEFUL". + The request shall be treated as if the "stopType" attribute has been set to "FORCEFUL", + when the "changeStateTo" attribute is equal to "STOPPED" and the "stopType" attribute + is absent. required: - changeStateTo properties: @@ -268,32 +290,12 @@ definitions: $ref: "../../../definitions/SOL002SOL003VNFLifecycleManagement_def.yaml#/definitions/VnfOperationalStateType" stopType: description: > - It signals whether forceful or graceful stop is requested. - The “stopType” and “gracefulStopTimeout” attributes shall be absent, - when the “changeStateTo” attribute is equal to “STARTED”. The - “gracefulStopTimeout” attribute shall be present, when the - “changeStateTo” is equal to “STOPPED” and the “stopType” attribute - is equal to “GRACEFUL”. The “gracefulStopTimeout” attribute shall be - absent, when the “changeStateTo” attribute is equal to “STOPPED” and - the “stopType” attribute is equal to “FORCEFUL”. The request shall - be treated as if the “stopType” attribute was set to ”FORCEFUL”, when - the “changeStateTo” attribute is equal to “STOPPED” and the - “stopType” attribute is absent. + It signals whether forceful or graceful stop is requested. See note. $ref: "#/definitions/StopType" gracefulStopTimeout: description: > - The time interval (in seconds) to wait for the VNF to be taken out - of service during graceful stop, before stopping the VNF. - The “stopType” and “gracefulStopTimeout” attributes shall be absent, - when the “changeStateTo” attribute is equal to “STARTED”. The - “gracefulStopTimeout” attribute shall be present, when the - “changeStateTo” is equal to “STOPPED” and the “stopType” attribute - is equal to “GRACEFUL”. The “gracefulStopTimeout” attribute shall be - absent, when the “changeStateTo” attribute is equal to “STOPPED” and - the “stopType” attribute is equal to “FORCEFUL”. The request shall - be treated as if the “stopType” attribute was set to ”FORCEFUL”, when - the “changeStateTo” attribute is equal to “STOPPED” and the - “stopType” attribute is absent. + The time interval (in seconds) to wait for the VNF to be taken out of service + during graceful stop, before stopping the VNF. See note. type: integer additionalParams: description: > @@ -336,10 +338,21 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/KeyValuePairs" ChangeCurrentVnfPkgRequest: - #SOL003 location: 5.5.2.11a description: > This type represents request parameters for the "Change current VNF package" - operation to replace the VNF package on which a VNF instance is based. + operation to replace the VNF package on which a VNF instance is based. + It shall comply with the provisions defined in table 5.5.2.11a-1. + + NOTE 1: 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. + NOTE 2: It is possible to have several ExtManagedVirtualLinkData for the same VNF internal + VL in case of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkData + corresponding to the same VNF internal VL shall indicate so by referencing to the same + VnfVirtualLinkDesc and externally-managed multi-site VL instance (refer to clause 4.4.1.12). type: object required: - vnfdId @@ -358,17 +371,7 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/ExtVirtualLinkData" extManagedVirtualLinks: description: > - Information about internal VLs that are managed by the NFVO. - - NOTES: - 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. - It is possible to have several ExtManagedVirtualLinkData for the same VNF internal VL in case of a multi-site - VNF spanning several VIMs. The set of ExtManagedVirtualLinkData corresponding to the same VNF internal - VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed multi-site VL - instance (refer to clause 4.4.1.12). + Information about internal VLs that are managed by the NFVO. See notes 1 and 2. type: array items: $ref: "#/definitions/ExtManagedVirtualLinkData" @@ -452,12 +455,18 @@ definitions: VnfInfoModifications: description: > - This type represents attribute modifications that were performed on an - "Individual VNF instance" resource. The attributes that can be included - consist of those requested to be modified explicitly in the - "VnfInfoModificationRequest" data structure, and additional attributes - of the "VnfInstance" data structure that were modified implicitly e.g. - when modifying the referenced VNF package. + This type represents attribute modifications that were performed on an "Individual + VNF instance" resource. The attributes that can be included consist of those requested + to be modified explicitly in the "VnfInfoModificationRequest" data structure, and + additional attributes of the "VnfInstance" data structure that were modified implicitly + e.g. when modifying the referenced VNF package. + The "VnfInfoModifications" data type shall comply with the provisions defined in table + 5.5.2.12a-1. + + NOTE: If present, this attribute (which depends on the value of the "vnfdId" attribute) + was modified implicitly following a request to modify the "vnfdId" attribute, by + copying the value of this attribute from the VNFD in the VNF Package identified by + the "vnfdId" attribute. type: object properties: vnfInstanceName: @@ -503,38 +512,23 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier" vnfProvider: description: > - If present, this attribute signals modifications of the - "vnfProvider" attribute in "VnfInstance". - If present, this attribute (which depends on the value of the - "vnfPkgId" attribute) was modified implicitly following a request to - modify the "vnfPkgId" attribute, by copying the value of this - attribute from the VNFD in the VNF Package identified by the - "vnfPkgId” attribute. + If present, this attribute signals modifications of the "vnfProvider" attribute + in "VnfInstance". See note. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/String" vnfProductName: description: > - If present, this attribute signals modifications of the - "vnfProductName" attribute in "VnfInstance". - If present, this attribute (which depends on the value of the - "vnfPkgId" attribute) was modified implicitly following a request to - modify the "vnfPkgId" attribute, by copying the value of this - attribute from the VNFD in the VNF Package identified by the - "vnfPkgId” attribute. + If present, this attribute signals modifications of the "vnfProductName" attribute + in "VnfInstance". See note. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/String" vnfSoftwareVersion: description: > - If present, this attribute signals modifications of the - "vnfSoftwareVersion" attribute in "VnfInstance". + If present, this attribute signals modifications of the "vnfSoftwareVersion" attribute + in "VnfInstance". See note. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Version" vnfdVersion: description: > - If present, this attribute signals modifications of the - "vnfdVersion" attribute in "VnfInstance". - If present, this attribute (which depends on the value of the - "vnfPkgId" attribute) was modified implicitly following a request to - modify the "vnfPkgId" attribute, by copying the value of this - attribute from the VNFD in the VNF Package identified by the - "vnfPkgId” attribute. + If present, this attribute signals modifications of the "vnfdVersion" attribute + in "VnfInstance". See note. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Version" StopType: @@ -579,17 +573,18 @@ definitions: CreateVnfSnapshotInfoRequest: description: | - This type represents request parameters for the creation of an "Individual VNF snapshot" resource which can be - populated with content obtained by invoking the "Create VNF snapshot" LCM operation or extracted from a - VNF snapshot package. It shall comply with the provisions defined in table 5.5.2.20-1. + This type represents request parameters for the creation of an "Individual VNF snapshot" + resource which can be populated with content obtained by invoking the "Create VNF snapshot" + LCM operation or extracted from a VNF snapshot package. It shall comply with the provisions + defined in table 5.5.2.20-1. + + NOTE: The present attribute shall be provided if the "Individual VNF snapshot" resource is + requested to be created as part of a VNF snapshot package extraction. type: object properties: vnfSnapshotPkgId: description: | - Identifier of the VNF snapshot package information held by the NFVO. - - The present attribute shall be provided if the "Individual VNF snapshot" resource is requested to be created - as part of a VNF snapshot package extraction. + Identifier of the VNF snapshot package information held by the NFVO. See note. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier" vnfSnapshot: description: | @@ -656,7 +651,36 @@ definitions: VnfInstance: description: > - This type represents a VNF instance. + This type represents a VNF instance. It shall comply with the provisions defined in table 5.5.2.2-1. + + NOTE: Clause B.3.2 provides examples illustrating the relationship among the different run-time + information elements (CP, VL and link ports) used to represent the connectivity of a VNF. + + NOTE 1: Modifying the value of this attribute shall not be performed when conflicts exist between + the previous and the newly referred VNF package, i.e. when the new VNFD is changed with + respect to the previous VNFD in other aspects than merely referencing to other VNF software + images. In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded + VNF Package, the values of attributes in the VnfInstance that have corresponding attributes + in the VNFD shall be kept in sync with the values in the VNFD. + NOTE 2: ETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. + NOTE 3: VNF configurable properties are sometimes also referred to as configuration parameters applicable + to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated, + some are set prior to instantiation (are part of initial configuration) and can be modified later, + and others can be set only after instantiation. The applicability of certain configuration may + depend on the VNF and the required operation of the VNF at a certain point in time. + NOTE 4: Upon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes + of "vnfConfigurableProperties", "metadata" and "extensions" that were declared in the VNFD with a defined + initial value. The defined initial values can be declared in the VNFD, and/or, in case of "metadata", + obtained from the "CreateVnfRequest" structure. Child attributes of "vnfConfigurableProperties", + "metadata" and "extensions" that have no defined initial value shall not be created, in order to be + consistent with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null + values as deletion request. + NOTE 5: It is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a + multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same + VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed + multi-site VL instance (refer to clause 5.5.3.3). + NOTE 6: Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall + not be listed in the "vnfVirtualLinkResourceInfo" attribute as this would be redundant. type: object required: - id @@ -683,15 +707,7 @@ definitions: type: string vnfdId: description: > - Identifier of the VNFD on which the VNF instance is based. - - Modifying the value of this attribute shall not be performed when conflicts - exist between the previous and the newly referred VNF package, - i.e. when the new VNFD is not changed with respect to the previous VNFD - in other aspects than merely referencing to other VNF software images. - In order to avoid misalignment of the VnfInstance with the current VNF's - on-boarded VNF Package, the values of attributes in the VnfInstance that - have corresponding attributes in the VNFD shall be kept in sync with the values in the VNFD. + Identifier of the VNFD on which the VNF instance is based. See note 1. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier" vnfProvider: description: > @@ -711,44 +727,37 @@ definitions: $ref: "../../..//definitions/SOL002SOL003_def.yaml#/definitions/Version" vnfConfigurableProperties: description: > - Current values of the configurable properties of the VNF instance. - Configurable properties referred in this attribute are declared in - the VNFD. - ETSI GS NFV-SOL 001 specifies the structure and format of the VNFD - based on TOSCA specifications. - VNF configurable properties are sometimes also referred to as - configuration parameters applicable to a VNF. Some of these are set - prior to instantiation and cannot be modified if the VNF is - instantiated, some are set prior to instantiation (are part of - initial configuration) and can be modified later, and others can be - set only after instantiation. The applicability of certain - configuration may depend on the VNF and the required operation of - the VNF at a certain point in time. - These configurable properties include the following standard - attributes, which are declared in the VNFD if auto-scaling and/or - auto-healing are supported by the VNF: - * isAutoscaleEnabled: If present, the VNF supports auto-scaling. If - set to true, auto-scaling is currently enabled. If set to false, - auto-scaling is currently disabled. - * isAutohealEnabled: If present, the VNF supports auto-healing. If - set to true, auto-healing is currently enabled. If set to false, - auto-healing is currently disabled. - These configurable properties can be initialized with default values - from the VNFD. - Configurable properties can be modified with values passed in the request - structures of certain LCM operations, such as the InstantiateVnfRequest - structure. - Further, these configurable properties can be created, modified or - deleted with the PATCH method. - In addition, the provisions in clause 5.7 shall apply. + Additional VNF-specific attributes that provide the current values of the configurable + properties of the VNF instance. + + These attributes represent values that are stored persistently in the VnfInstance structure + and that correspond to configuration parameters of the VNF instance. + + Modifying these attributes affects the configuration of the VNF instance either directly + (if the VNF instance is in INSTANTIATED state at the time of the modification) or as part + of the subsequent VNF instantiation operation (if the VNF instance is in NOT_INSTANTIATED + state at the time of the modification). + + Configurable properties referred in these attributes are declared in the VNFD. The declaration + of configurable properties in the VNFD can optionally contain the specification of initial values. + See notes 2, 3 and 4. The VNFM shall reject requests to write configurable properties that are + not declared in the VNFD with a "422 Unprocessable entity" error response as defined in clause + 6.4 of ETSI GS NFV SOL 013. + + These configurable properties include the following standard attributes, which are declared in + the VNFD if auto-scaling and/or auto-healing are supported by the VNF: + - isAutoscaleEnabled: If present, the VNF supports auto-scaling. If set to true, auto-scaling + is currently enabled. If set to false, auto-scaling is currently disabled. + - isAutohealEnabled: If present, the VNF supports auto-healing. If set to true, auto-healing is + currently enabled. If set to false, auto-healing is currently disabled. - NOTE: Upon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes - of "vnfConfigurableProperties", "metadata" and "extensions" that were declared in the VNFD with a defined - initial value. The defined initial values can be declared in the VNFD, and/or, in case of "metadata", - obtained from the "CreateVnfRequest" structure. Child attributes of "vnfConfigurableProperties", "metadata" - and "extensions" that have no defineddeclared initial value shall not be created, in order to be consistent - with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null values as deletion - request. + These configurable properties can be initialized with default values from the VNFD (see note 4). + + Configurable properties can be modified with values passed in the request structures of certain + LCM operations, such as the InstantiateVnfRequest structure. + + Further, these configurable properties can be created, modified or deleted with the PATCH method. + In addition, the provisions in clause 5.7 shall apply. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/KeyValuePairs" vimConnectionInfo: description: > @@ -830,15 +839,7 @@ definitions: $ref: "../../../definitions/SOL002SOL003VNFLifecycleManagement_def.yaml#/definitions/ExtVirtualLinkInfo" extManagedVirtualLinkInfo: description: > - Information about the externally-managed internal VLs of the VNF instance. - - NOTE: It is possible to have several ExtManagedVirtualLinkInfo for the same - VNF internal VL in case of a multi-site VNF spanning several VIMs. The set of - ExtManagedVirtualLinkInfo corresponding to the same VNF internal VL shall indicate - so by referencing to the same VnfVirtualLinkDesc and externally-managed multi-site - VL instance (refer to clause 5.5.3.3). - Even though externally-managed internal VLs are also used for VNF-internal connectivity, - they shall not be listed in the "vnfVirtualLinkResourceInfo" attribute as this would be redundant. + Information about the externally-managed internal VLs of the VNF instance. See note 5 and note 6. type: array items: $ref: "#/definitions/ExtManagedVirtualLinkInfo" @@ -863,11 +864,9 @@ definitions: type: array items: $ref: "#/definitions/VnfcResourceInfo" - virtualLinkResourceInfo: + vnfVirtualLinkResourceInfo: description: > - Information about the virtualised network resources used by the VLs - of the VNF instance. Even though externally-managed internal VLs are also used for VNF-internal - connectivity, they shall not be listed in the "vnfVirtualLinkResourceInfo" attribute as this would be redundant. + Information about the virtualised network resources used by the VLs of the VNF instance. See note 6. type: array items: $ref: "#/definitions/VnfVirtualLinkResourceInfo" @@ -880,52 +879,49 @@ definitions: metadata: description: > Additional VNF-specific attributes that provide metadata describing the VNF instance. - These attributes represent values that are stored persistently in the VnfInstance structure - for consumption by functional blocks that invoke the VNF lifecycle management interface. - They are not consumed by the VNFM, or the lifecycle management scripts. - Modifying the values of these attributes has no effect on the VNF instance, it only affects - the information represented in the VnfInstance structure. - Metadata that are writeable are the VNF provider foresees are expected to be declared in the VNFD. - The declaration of metadata in the VNFD can optionally contain the specification of initial values. + + These attributes represent values that are stored persistently in the VnfInstance structure for + consumption by functional blocks that invoke the VNF lifecycle management interface. They are not + consumed by the VNFM, or the lifecycle management scripts. + + Modifying the values of these attributes has no effect on the VNF instance, it only affects the + information represented in the VnfInstance structure. + + Metadata that the VNF provider foresees are expected to be declared in the VNFD. The declaration + of metadata in the VNFD can optionally contain the specification of initial values. See notes 2 and 4. The VNFM shall accept requests to write metadata that are not declared in the VNFD. - These attributes can be initialized with default values from the VNFD or with values + + These attributes can be initialized with default values from the VNFD (see note 4) or with values passed in the CreateVnfRequest structure (see clause 5.4.2.3.1). - This attributeThese attributes can be created, modified or removed with the PATCH method. - - ETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. - Upon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes - of "vnfConfigurableProperties", "metadata" and "extensions" that were declared in the VNFD with - a defined initial value. Child attributes of "vnfConfigurableProperties", "metadata" and "extensions" - that have no declared initial value shall not be created, in order to be consistent with the semantics - of the JSON Merge Patch method (see IETF RFC 7396) that interprets null values as deletion request. + + These attributes can be created, modified or removed with the PATCH method. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/KeyValuePairs" extensions: description: > Additional VNF-specific attributes that affect the lifecycle management of this VNF instance. - These attributes represent values that are stored persistently in the VnfInstance structure - for consumption by the VNFM or the lifecycle management scripts during the execution of - VNF lifecycle management operations. - All extensions that are allowed for the VNF are declared in the VNFD. The declaration of an extension - in the VNFD contains information on whether its presence is optional or required, and optionally - can specify an initial value. See note 2 and note 4. The VNFM shall reject requests to write extension - attributes that are not declared in the VNFD with a "422 Unprocessable entity" error response as defined - in clause 6.4 of ETSI GS NFV-SOL 013. - Modifying the values of these attributes has no direct effect on the VNF instance; however, the modified - attribute values can be considered during subsequent VNF lifecycle management operations, which means that + + These attributes represent values that are stored persistently in the VnfInstance structure for + consumption by the VNFM or the lifecycle management scripts during the execution of VNF lifecycle + management operations. + + All extensions that are allowed for the VNF are declared in the VNFD. The declaration of an extension + in the VNFD contains information on whether its presence is optional or required, and optionally can + specify an initial value. See notes 2 and 4. The VNFM shall reject requests to write extension attributes + that are not declared in the VNFD with a "422 Unprocessable entity" error response as defined in clause + 6.4 of ETSI GS NFV-SOL 013. + + Modifying the values of these attributes has no direct effect on the VNF instance; however, the modified + attribute values can be considered during subsequent VNF lifecycle management operations, which means that the modified values can indirectly affect the configuration of the VNF instance. - These attributes can be initialized with default values from the VNFD. - These attributes can be modified with values passed in the request structures of certain LCM operations, + + These attributes can be initialized with default values from the VNFD (see note 4). + + These attributes can be modified with values passed in the request structures of certain LCM operations, such as the InstantiateVnfRequest structure. + Further, these attributes can be created, modified or deleted with the PATCH method. + In addition, the provisions in clause 5.7 shall apply. - - NOTE: Upon creation of the VnfInstance structure, the VNFM shall create and initialize all child attributes - of "vnfConfigurableProperties", "metadata" and "extensions" that were declared in the VNFD with a defined - initial value. The defined initial values can be declared in the VNFD, and/or, in case of "metadata", - obtained from the "CreateVnfRequest" structure. Child attributes of "vnfConfigurableProperties", "metadata" - and "extensions" that have no defineddeclared initial value shall not be created, in order to be consistent - with the semantics of the JSON Merge Patch method (see IETF RFC 7396) that interprets null values as deletion - request. _links: description: > Links to resources related to this resource. @@ -1095,8 +1091,17 @@ definitions: VnfcResourceInfo: description: > - This type represents the information on virtualised compute and storage - resources used by a VNFC in a VNF instance. + This type represents the information on virtualised compute and storage resources + used by a VNFC in a VNF instance. It shall comply with the provisions defined in + table 5.5.3.5-1. + + NOTE 1: ETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on + TOSCA specifications. + NOTE 2: A VNFC CP is "connected to" an external CP if the VNFC CP is connected to an + internal VL that exposes an external CP. A VNFC CP is "exposed as" an external + CP if it is connected directly to an external VL. + NOTE 3: The information can be omitted because it is already available as part of the + external CP information. type: object required: - id @@ -1109,7 +1114,7 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" vduId: description: > - Reference to the applicable VDU in the VNFD. + Reference to the applicable VDU in the VNFD. See note 1. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnfd" vnfdId: description: > @@ -1142,12 +1147,9 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier" vnfcCpInfo: description: > - All the CPs of the VNFC instance. - Shall be present when that particular CP of the VNFC instance is exposed as an external CP of the VNF instance - or is connected to an external CP of the VNF instance. - A VNFC CP is "connected to" an external CP if the VNFC CP is connected to an internal VL that exposes an external CP. - A VNFC CP is "exposed as" an external CP if it is connected directly to an external VL. - May be present otherwise. + CPs of the VNFC instance. Shall be present when that particular CP of the VNFC instance + is exposed as an external CP of the VNF instance or is connected to an external CP of the + VNF instance. See note 2. May be present otherwise. type: array items: type: object @@ -1162,20 +1164,18 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" cpdId: description: > - Identifier of the VDU CPD, cpdId, in the VNFD. + Identifier of the VDU CPD, cpdId, in the VNFD. See note 1. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnfd" vnfExtCpId: description: > - Identifier of the related external CP. Shall be present when the VNFC CP is exposed as an external CP of - the VNF instance or connected to an external CP of the VNF instance (see note) and shall be absent otherwise. - - NOTE: A VNFC CP is "connected to" an external CP if the VNFC CP is connected to an internal VL that exposes - an external CP. A VNFC CP is "exposed as" an external CP if it is connected directly to an external VL. + Identifier of the related external CP. Shall be present when the VNFC CP is exposed as an + external CP of the VNF instance or connected to an external CP of the VNF instance (see note 2) + and shall be absent otherwise. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" cpProtocolInfo: description: > - Network protocol information for this CP. May be omitted if the VNFC CP is exposed as an external CP. - The information can be omitted because it is already available as part of the external CP information. + Network protocol information for this CP. May be omitted if the VNFC CP is exposed as an external CP. + See note 3. type: array items: $ref: "../../../definitions/SOL002SOL003VNFLifecycleManagement_def.yaml#/definitions/CpProtocolInfo" @@ -1344,7 +1344,16 @@ definitions: VnfcSnapshotInfo: description: > - This type represents a VNFC snapshot. + This type represents a VNFC snapshot. It shall comply with the provisions defined in table 5.5.3.19-1. + + NOTE 1: The identifier of the compute snapshot resource is assigned during creation of a VNFC snapshot + being returned from the VIM as output data in the response message of the individual resource + operations. This attribute shall only be present for a VNFC snapshot that has been newly created + by the VNFM as a result of the "Create VNF snapshot task". + NOTE 2: The identifier of the storage snapshot resource is assigned during creation of a VNFC snapshot being + returned from the VIM as output data in the response message of the individual resource operations. + This attribute shall only be present for a VNFC snapshot with an associated storage resource and that + has been newly created by the VNFM as a result of the "Create VNF snapshot task". type: object required: - id @@ -1380,11 +1389,7 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" computeSnapshotResource: description: > - Reference to a compute snapshot resource. - The identifier of the compute snapshot resource is assigned during creation of a VNFC snapshot - being returned from the VIM as output data in the response message of the individual resource operations. - This attribute shall only be present for a VNFC snapshot that has been newly created by the VNFM as a result o - f the "Create VNF snapshot task". + Reference to a compute snapshot resource. See note 1. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/ResourceHandle" storageSnapshotResources: description: > @@ -1404,12 +1409,7 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" storageSnapshotResource: description: > - Reference to a storage snapshot resource. - The identifier of the storage snapshot resource is assigned during creation of a VNFC - snapshot being returned from the VIM as output data in the response message of the - individual resource operations. This attribute shall only be present for a VNFC snapshot - with an associated storage resource and that has been newly created by the VNFM as a - result of the "Create VNF snapshot task". + Reference to a storage snapshot resource. See note 2. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/KeyValuePairs" userDefinedData: description: > @@ -1472,8 +1472,14 @@ definitions: AffectedVnfc: description: > - This type provides information about added, deleted, modified and - temporary VNFCs. + This type provides information about added, deleted, modified and temporary VNFCs. + It shall comply with the provisions in table 5.5.3.13-1. + + NOTE: The "resourceDefinitionId" attribute provides information to the API consumer + (i.e. the NFVO) to assist in correlating the resource changes performed during + the LCM operation with the granted resources in a specific Grant exchange, which + is identified by the "grantId" available in the "Individual VNF lifecycle management + operation occurrence" and the "id" in the "Individual Grant". type: object required: - id @@ -1519,9 +1525,8 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/ResourceHandle" resourceDefinitionId: description: > - The identifier of the "ResourceDefinition" in the granting exchange - related to the LCM operation occurrence. It shall be present when - an applicable GrantInfo for thegranted resource exists. See note. + The identifier of the "ResourceDefinition" in the granting exchange related to the LCM operation occurrence. + It shall be present when an applicable GrantInfo for thegranted resource exists. See note. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierLocal" zoneId: description: > @@ -1568,8 +1573,27 @@ definitions: VnfLcmOpOcc: description: > - This type represents a VNF lifecycle management operation occurrence. Shall be set to the value of the "id" - attribute in the "Grant" representing the associated "Individual Grant", if such grant exists. + This type represents a VNF lifecycle management operation occurrence. + It shall comply with the provisions defined in table 5.5.2.13-1. + + NOTE 1: This allows the NFVO to obtain the information contained in the latest + "result" notification if it has not received it due to an error or a + wrongly configured subscription filter. + NOTE 2: Not more than one of changedInfo and modificationsTriggeredByVnfPkgChange + shall be present. + NOTE 3: For a particular affected VL, there shall be as many "AffectedVirtualLink" + entries as needed for signalling the different types of changes, i.e. one + per virtual link and change type. For instance, in the case of signaling + affected VL instances involving the addition of a particular VL instance + with links ports, one "AffectedVirtualLink" entry signals the addition of + the VL by using the "changeType" attribute of "AffectedVirtualLink" structure + equal to "ADDED", and another "AffectedVirtualLink" entry signals the addition + of externally visible VNF link ports of the VL by using the "changeType" equal + to "LINK_PORT_ADDED". + NOTE 4: A coordination action has timed out if the VNFM has not been able to read the + "Individual coordination action" resource within a timeout interval after requesting + the coordination to be started or to be cancelled. The length of the timeout interval + is defined by means outside the scope of the present document. type: object oneOf: - required: @@ -1674,60 +1698,37 @@ definitions: properties: affectedVnfcs: description: > - Information about VNFC instances that were affected during the - lifecycle operation. - This allows the API consumer to obtain the information contained in - the latest "result" notification if it has not received it due to an - error or a wrongly configured subscription filter. + Information about VNFC instances that were affected during the lifecycle operation. + See note 1. type: array items: $ref: "#/definitions/AffectedVnfc" affectedVirtualLinks: description: > - Information about VL instances that were affected during the - lifecycle operation. - This allows the API consumer to obtain the information contained in - the latest "result" notification if it has not received it due to an - error or a wrongly configured subscription filter. - For a particular affected VL, there shall be as many "AffectedVirtualLink" - entries as needed for signalling the different types of changes, i.e., - one per virtual link and change type. For instance, in the case of - signaling affected VL instances involving the addition of a particular VL - instance with links ports, one "AffectedVirtualLink" entry signals the - addition of the VL by using the "changeType" attribute of "AffectedVirtualLink" - structure equal to "ADDED", and another "AffectedVirtualLink" entry signals - the addition of VNF link ports of the VL by using the "changeType" equal to - "LINK_PORT_ADDED". + Information about VL instances that were affected during the lifecycle operation. + See notes 1 and 3. type: array items: $ref: "#/definitions/AffectedVirtualLink" affectedExtLinkPorts: description: > - Information about external VNF link ports that were affected during the lifecycle operation. This allows - the API consumer to obtain the information contained in the latest "result" notification if it has not - received it due to an error or a wrongly configured subscription filter. + Information about external VNF link ports that were affected during the lifecycle operation. + See note 1. type: array items: $ref: "#/definitions/AffectedExtLinkPort" affectedVirtualStorages: description: > - Information about virtualised storage instances that were affected - during the lifecycle operation. - This allows the API consumer to obtain the information contained - in the latest "result" notification if it has not received it due to - an error or a wrongly configured subscription filter. + Information about virtualised storage instances that were affected during the lifecycle operation. + See note 1. type: array items: $ref: "#/definitions/AffectedVirtualStorage" changedInfo: description: > - Information about the changed VNF instance information, including - VNF configurable properties, if applicable. - This allows the NFVO to obtain the information contained in the - latest "result" notification if it has not received it due to an - error or a wrongly configured subscription filter. + Information about the changed VNF instance information, including VNF configurable properties, + if applicable. See note 1 and note 2. $ref: "#/definitions/VnfInfoModifications" - affectedVipCps: description: > Information about virtual IP CP instances that were affected during @@ -1735,30 +1736,23 @@ definitions: type: array items: $ref: "../../../definitions/SOL002SOL003VNFLifecycleManagement_def.yaml#/definitions/AffectedVipCp" - changedExtConnectivity: description: > - Information about changed external connectivity, if applicable. - This allows the NFVO to obtain the information contained in the - latest "result" notification if it has not received it due to an - error or a wrongly configured subscription filter. + Information about changed external connectivity, if applicable. See note 1. type: array items: $ref: "../../../definitions/SOL002SOL003VNFLifecycleManagement_def.yaml#/definitions/ExtVirtualLinkInfo" modificationsTriggeredByVnfPkgChange: description: > - Information about performed changes of "VnfInstance" attributes triggered by changing the current VNF package, - if applicable. Shall be absent if the "operation" attribute is different from "CHANGE_VNFPKG". - This allows the API consumer to obtain the information contained in the latest "result" notification if it has - not received it due to an error or a wrongly configured subscription filter. - Not more than one of changedInfo and modificationsTriggeredByVnfPkgChange shall be present. + Information about performed changes of "VnfInstance" attributes triggered by changing the current VNF package, + if applicable. Shall be absent if the "operation" attribute is different from "CHANGE_VNFPKG". + See notes 1 and 2. $ref: "../../../definitions/SOL002SOL003VNFLifecycleManagement_def.yaml#/definitions/ModificationsTriggeredByVnfPkgChange" vnfSnapshotInfoId: description: > Identifier of the "individual VNF snapshot" resource. Shall be present if applicable to the type of LCM operation, i.e., if the value of the "operation" attribute is either "CREATE_SNAPSHOT" or "REVERT_TO_SNAPSHOT". $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier" - lcmCoordinations: description: > Information about LCM coordination actions (see clause 10 in ETSI GS NFV-SOL002) related to this LCM operation occurrence. @@ -1781,37 +1775,31 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier" coordinationResult: description: > - The result of executing the coordination action which also implies the action to be performed by the VNFM as the result of this coordination. - Shall be present if the coordination has been finished. Shall be absent if the coordination is ongoing or has timed out - A coordination action has timed out if the VNFM has not been able to read the "Individual coordination action" resource within a timeout - interval after requesting the coordination to be started or to be cancelled. The length of the timeout interval is defined by means outside - the scope of the present document. + The result of executing the coordination action which also implies the action to be performed by the VNFM as + the result of this coordination. + + Shall be present if the coordination has been finished. Shall be absent if the coordination is ongoing or has + timed out (see note 4). $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/LcmCoordResultType" - startTime: description: > The time when the coordination action has been started. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/DateTime" - - endTime: description: > - The end time of the coordination action. Shall be present for a coordination action that has finished or - timed out (see note 4) and shall be absent if the coordination is ongoing. + The end time of the coordination action. Shall be present for a coordination action that has finished or timed + out (see note 4) and shall be absent if the coordination is ongoing. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/DateTime" - endpointType: description: > The endpoint type used by this coordination action. Valid values: • MGMT: coordination with other operation supporting management systems (e.g. EM) • VNF: coordination with the VNF instance - type: string enum: - MGMT - VNF - warnings: description: > Warning messages that were generated while the operation was executing. @@ -1821,8 +1809,6 @@ definitions: type: array items: type: string - - _links: description: > Links to resources related to this resource. @@ -1875,7 +1861,13 @@ definitions: AffectedExtLinkPort: description: > - This type provides information about added and deleted external link ports (link ports attached to external virtual links). + This type provides information about added and deleted external link ports (link ports attached to external virtual links). + It shall comply with the provisions in table 5.5.3.14a-1. + + NOTE: The "resourceDefinitionId" attribute provides information to the API consumer (i.e. the NFVO) to assist in correlating + the resource changes performed during the LCM operation with the granted resources in a specific Grant exchange, which + is identified by the "grantId" available in the "Individual VNF lifecycle management operation occurrence" and the "id" + in the "Individual Grant". type: object required: - id @@ -1909,49 +1901,64 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/ResourceHandle" resourceDefinitionId: description: > - The identifier of the "ResourceDefinition" in the granting exchange related to the LCM operation occurrence. - It shall be present when an applicable GrantInfo for the granted resource exists. - The "resourceDefinitionId" attribute provides information to the API consumer (i.e. the NFVO) to assist in - correlating the resource changes performed during the LCM operation with the granted resources in a - specific Grant exchange, which is identified by the "grantId" available in the "Individual VNF lifecycle - management operation occurrence" and the "id" in the "Individual Grant". + The identifier of the "ResourceDefinition" in the granting exchange related to the LCM operation occurrence. + It shall be present when an applicable GrantInfo for the granted resource exists. See note. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierLocal" VnfLcmOperationOccurrenceNotification: description: > - This type represents a VNF lifecycle management operation occurrence - notification, which informs the receiver of changes in the VNF - lifecycle caused by a VNF LCM operation occurrence. The support of the - notification is mandatory. - This notification shall be triggered by the VNFM when there is a change in the state of a - VNF LCM operation occurrence that changes the VNF lifecycle, includingwhich represents an - occurrence of one the following LCM operations: - * Instantiation of the VNF - * Scaling of the VNF instance (including auto-scaling) - * Healing of the VNF instance (including auto-healing) - * Change of the state of the VNF instance (i.e. Operate VNF) - * Change of the deployment flavour of the VNF instance - * Change of the external connectivity of the VNF instance - * Termination of the VNF instance - * Modification of VNF instance information and/or VNF configurable - properties through the "PATCH" method on the "Individual VNF instance" - resource - * Creation of a VNF snapshot - * Reversion of the VNF instance to a VNF snapshot. - Clause 5.6.2 defines the states and state transition of a VNF LCM operation occurrence, - and also specifies details of the notifications to be emitted at each state transition. - If this is the initial notification about the start of a VNF LCM operation occurrence, - it is assumed that the notification is sent by the VNFM before any action (including sending the grant request) - is taken as part of the LCM operation. Due to possible race conditions, the "start" notification, - the grant request and the LCM operation acknowledgment (i.e. the "202 Accepted" response) - can arrive in any order at the NFVO, and the NFVO shall be able to handle such a situation. - If this is a notification about a final or intermediate result state of a VNF LCM operation occurrence, - the notification shall be sent after all related actions of the LCM operation that led - to this state have been executed. - The new state shall be set in the "Individual VNF LCM operation occurrence" resource before - the notification about the state change is sent. - See clause 5.6.2.2 for further provisions regarding sending this notification, including - in cases of handling LCM operation errors. + This type represents a VNF lifecycle management operation occurrence notification, which + informs the receiver of changes in the VNF lifecycle caused by a VNF LCM operation occurrence. + It shall comply with the provisions defined in table 5.5.2.17-1. + The support of the notification is mandatory. + + This notification shall be triggered by the VNFM when there is a change in the state of a VNF LCM + operation occurrence that changes the VNF lifecycle, which represents an occurrence of one the + following LCM operations: + - Instantiation of the VNF + - Scaling of the VNF instance (including auto-scaling) + - Healing of the VNF instance (including auto-healing) + - Change of the state of the VNF instance (i.e. Operate VNF) + - Change of the deployment flavour of the VNF instance + - Change of the external connectivity of the VNF instance + - Change of the current VNF package + - Termination of the VNF instance + - Modification of VNF instance information and/or VNF configurable properties through the "PATCH" + method on the "Individual VNF instance" resource + - Creation of a VNF snapshot + - Reversion of the VNF instance to a VNF snapshot + + Clause 5.6.2 defines the states and state transition of a VNF LCM operation occurrence, and also + specifies details of the notifications to be emitted at each state transition. + If this is the initial notification about the start of a VNF LCM operation occurrence, it is assumed + that the notification is sent by the VNFM before any action (including sending the grant request) is + taken as part of the LCM operation. Due to possible race conditions, the "start" notification, the grant + request and the LCM operation acknowledgment (i.e. the "202 Accepted" response) can arrive in any order + at the NFVO, and the NFVO shall be able to handle such a situation. + If this is a notification about a final or intermediate result state of a VNF LCM operation occurrence, + the notification shall be sent after all related actions of the LCM operation that led to this state have + been executed. + The new state shall be set in the "Individual VNF LCM operation occurrence" resource before the notification + about the state change is sent. + The amount of information provided in the LCM operation occurrence notifications to be issued by the VNFM when + a particular subscription matches can be controlled by the API consumer using the "verbosity" attribute in the + subscription request (see clause 5.5.2.15). The "verbosity" setting in a particular individual subscription shall + only apply to the LCM operation occurrence notifications triggered by that subscription. However, it shall not + affect the amount of information in the "VnfLcmOpOcc" structure (see clause 5.5.2.13) which represents the "Individual + LCM operation occurrence" resource associated with each of the notifications. + See clause 5.6.2.2 for further provisions regarding sending this notification, including in cases of handling LCM + operation errors. + + NOTE 1: Shall be present if the "notificationStatus" is set to "RESULT", the "verbosity" attribute is set to "FULL" + and the operation has performed any resource modification. Shall be absent otherwise. This attribute contains + information about the cumulative changes to virtualised resources that were performed so far by the VNF LCM + operation occurrence and by any of the error handling procedures for that operation occurrence. + NOTE 2: For a particular affected VL, there shall be as many "AffectedVirtualLink" entries as needed for signalling + the different types of changes, i.e. one per virtual link and change type. For instance, in the case of signaling + affected VL instances involving the addition of a particular VL instance with links ports, one "AffectedVirtualLink" + entry signals the addition of the VL by using the "changeType" attribute of "AffectedVirtualLink" structure equal to + "ADDED", and another "AffectedVirtualLink" entry signals the addition of externally visible VNF link ports of the VL + by using the "changeType" equal to "LINK_PORT_ADDED". type: object required: - id @@ -2035,63 +2042,25 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier" affectedVnfcs: description: > - Information about VNFC instances that were affected during the - lifecycle operation. - Shall be present if the "notificationStatus" is set to "RESULT", - the "verbosity" attribute is set to "FULL" and the operation has - performed any resource modification. Shall be absent otherwise. - This attribute contains information about the cumulative changes - to virtualised resources that were performed so far by the VNF LCM - operation occurrence and by any of the error handling procedures - for that operation occurrence. + Information about VNFC instances that were affected during the lifecycle operation. See note 1. type: array items: $ref: "#/definitions/AffectedVnfc" affectedVirtualLinks: description: > - Information about VL instances that were affected during the - lifecycle operation. - Shall be present if the "notificationStatus" is set to "RESULT" and - the operation has performed any resource modification. Shall be - absent otherwise. This attribute contains information about the - cumulative changes to virtualised resources that were performed so - far by the VNF LCM operation occurrence and by any of the error - handling procedures for that operation occurrence. - For a particular affected VL, there shall be as many "AffectedVirtualLink" - entries as needed for signalling the different types of changes, i.e., - one per virtual link and change type. For instance, in the case of signaling - affected VL instances involving the addition of a particular VL instance with - links ports, one "AffectedVirtualLink" entry signals the addition of the VL by - using the "changeType" attribute of "AffectedVirtualLink" structure equal to - "ADDED", and another "AffectedVirtualLink" entry signals the addition of VNF - link ports of the VL by using the "changeType" equal to "LINK_PORT_ADDED". + Information about VL instances that were affected during the lifecycle operation. See note 1 and note 2. type: array items: $ref: "#/definitions/AffectedVirtualLink" affectedExtLinkPorts: description: > - Information about external VNF link ports that were affected during - the lifecycle operation. - Shall be present if the "notificationStatus" is set to "RESULT", - the "verbosity" attribute is set to "FULL" and the operation has - performed any resource modification. Shall be absent otherwise. - This attribute contains information about the cumulative changes - to virtualised resources that were performed so far by the VNF LCM - operation occurrence and by any of the error handling procedures - for that operation occurrence. + Information about external VNF link ports that were affected during the lifecycle operation. See note 1. type: array items: $ref: "#/definitions/AffectedExtLinkPort" affectedVirtualStorages: description: > - Information about virtualised storage instances that were affected - during the lifecycle operation. - Shall be present if the "notificationStatus" is set to "RESULT" and - the operation has performed any resource modification. Shall be - absent otherwise. This attribute contains information about the - cumulative changes to virtualised resources that were performed so - far by the VNF LCM operation occurrence and by any of the error - handling procedures for that operation occurrence. + Information about virtualised storage instances that were affected during the lifecycle operation. See note 1. type: array items: $ref: "#/definitions/AffectedVirtualStorage" @@ -2248,8 +2217,13 @@ definitions: AffectedVirtualStorage: description: > - This type provides information about added, deleted, modified and - temporary virtual storage resources. + This type provides information about added, deleted, modified and temporary virtual storage resources. + It shall comply with the provisions in table 5.5.3.15-1. + + NOTE: The "resourceDefinitionId" attribute provides information to the API consumer (i.e. the NFVO) to + assist in correlating the resource changes performed during the LCM operation with the granted + resources in a specific Grant exchange, which is identified by the "grantId" available in the + "Individual VNF lifecycle management operation occurrence" and the "id" in the "Individual Grant". type: object required: - id @@ -2295,15 +2269,8 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/ResourceHandle" resourceDefinitionId: description: > - The identifier of the "ResourceDefinition" in the granting exchange - related to the LCM operation occurrence. It shall be present when an - applicable GrantInfo for the granted resource exists. - The "resourceDefinitionId" attribute provides information to the API - consumer (i.e. the NFVO) to assist in correlating the resource changes - performed during the LCM operation with the granted resources in a - specific Grant exchange, which is identified by the "grantId" available - in the "Individual VNF lifecycle management operation occurrence" and - the "id" in the "Individual Grant". + The identifier of the "ResourceDefinition" in the granting exchange related to the LCM operation occurrence. + It shall be present when an applicable GrantInfo for the granted resource exists. See note. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierLocal" zoneId: description: > diff --git a/src/SOL003/VNFLifecycleOperationGranting/definitions/SOL003VNFLifecycleOperationGranting_def.yaml b/src/SOL003/VNFLifecycleOperationGranting/definitions/SOL003VNFLifecycleOperationGranting_def.yaml index 0ff399b2..cac56837 100644 --- a/src/SOL003/VNFLifecycleOperationGranting/definitions/SOL003VNFLifecycleOperationGranting_def.yaml +++ b/src/SOL003/VNFLifecycleOperationGranting/definitions/SOL003VNFLifecycleOperationGranting_def.yaml @@ -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 @@ -877,7 +782,20 @@ definitions: SnapshotResourceDefinition: 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 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: diff --git a/src/SOL003/VNFPackageManagement/definitions/SOL003VNFPackageManagement_def.yaml b/src/SOL003/VNFPackageManagement/definitions/SOL003VNFPackageManagement_def.yaml index 5711bddd..b65b2b57 100644 --- a/src/SOL003/VNFPackageManagement/definitions/SOL003VNFPackageManagement_def.yaml +++ b/src/SOL003/VNFPackageManagement/definitions/SOL003VNFPackageManagement_def.yaml @@ -4,7 +4,13 @@ definitions: VnfPkgInfo: description: > - This type represents the information of an VNF package. + This type represents the information of a VNF package. It shall comply with the provisions defined in table 10.5.2.2-1. + + NOTE 1: If the value of the onboardingState attribute is not equal to "ONBOARDED", the value of the operationalState + attribute shall be equal to "DISABLED". + NOTE 2: If the value of the onboardingState attribute is not equal to "ONBOARDED", the value of the usageState attribute + shall be equal to "NOT_IN_USE". + NOTE 3: ETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. type: object required: - id @@ -111,23 +117,15 @@ definitions: $ref: "#/definitions/PackageOnboardingStateType" operationalState: description: > - Operational state of the VNF package. - If the value of the onboardingState attribute is not equal to - "ONBOARDED", the value of the operationalState attribute shall be - equal to "DISABLED". + Operational state of the VNF package. See note 1. $ref: "#/definitions/PackageOperationalStateType" usageState: description: > - Usage state of the VNF package. - If the value of the onboardingState attribute is not equal to - "ONBOARDED", the value of the usageState attribute shall be - equal to "NOT_IN_USE". + Usage state of the VNF package. See note 2. $ref: "#/definitions/PackageUsageStateType" vnfmInfo: description: > - Specifies VNFMs compatible with the VNF. This information is copied from the VNFD. - ETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on - TOSCA specifications. + Specifies VNFMs compatible with the VNF. This information is copied from the VNFD. See note 3. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/String" userDefinedData: description: > @@ -229,9 +227,13 @@ definitions: VnfPackageSoftwareImageInfo: description: > - This type represents an artifact contained in or external to a VNF package which - represents a software image. - It shall comply with provisions defined in table 10.5.3.2-1. + This type represents an artifact contained in or external to a VNF package which represents a software image. + It shall comply with the provisions defined in table 10.5.3.2-1. + + NOTE 1: The list of permitted values was taken from "Container formats" in OpenStack® documentation: "Disk and container formats for images" + (Available at https://docs.openstack.org/glance/pike/user/formats.html). + NOTE 2: The list of permitted values was adapted from "Disk formats" in OpenStack® documentation: "Disk and container formats for images" + (Available at https://docs.openstack.org/glance/pike/user/formats.html). type: object required: - id @@ -284,8 +286,7 @@ definitions: - DOCKER: docker container format - OVA: OVF package in a tarfile - OVF: OVF container format - The list of permitted values was taken from "Container formats" in - http://docs.openstack.org/image-guide/image-formats.html + See note 1. type: string enum: - AKI @@ -312,8 +313,7 @@ definitions: - VHD: a common disk image format - VHDX: enhanced version of VHD format - VMDK: a common disk image format - The list of permitted values was adapted from "Disk formats" in - http://docs.openstack.org/image-guide/image-formats.html + See note 2. type: string enum: - AKI @@ -456,14 +456,18 @@ definitions: PkgmNotificationsFilter: description: > - This type represents a subscription filter related to notifications - related to VNF package management. - At a particular nesting level in the filter structure, the following - applies: All attributes shall match in order for the filter to match - (logical "and" between different filter attributes). If an attribute - is an array, the attribute shall match if at least one of the values - in the array matches (logical "or" between the values of one filter - attribute). + This type represents a subscription filter related to notifications related to VNF package management. + It shall comply with the provisions defined in table 10.5.3.4-1. + At a particular nesting level in the filter structure, the following applies: All attributes shall match + in order for the filter to match (logical "and" between different filter attributes). If an attribute is + an array, the attribute shall match if at least one of the values in the array matches (logical "or" + between the values of one filter attribute). + + NOTE 1: The permitted values of the "notificationTypes" attribute are spelled exactly as the names of the + notification types to facilitate automated code generation systems. + NOTE 2: The attributes "vnfProductsFromProviders", "vnfdId" and "vnfPkgId" are alternatives to reference to + particular VNF packages in a filter. They should not be used both in the same filter instance, but + one alternative should be chosen. type: object anyOf: - oneOf: @@ -480,9 +484,7 @@ definitions: Permitted values: - VnfPackageOnboardingNotification - VnfPackageChangeNotification - The permitted values of the "notificationTypes" attribute are - spelled exactly as the names of the notification types to - facilitate automated code generation systems. + See note 1. type: array items: type: string @@ -493,10 +495,7 @@ definitions: description: > If present, match VNF packages that contain VNF products from certain providers. - The attributes "vnfProductsFromProviders", "vnfdId" and "vnfPkgId" - are alternatives to reference to particular VNF packages in a - filter. They should not be used both in the same filter instance, - but one alternative should be chosen. + See note 2. type: array items: type: object @@ -548,10 +547,7 @@ definitions: vnfdId: description: > Match VNF packages with a VNFD identifier listed in the attribute. - The attributes "vnfProductsFromProviders", "vnfdId" and "vnfPkgId" - are alternatives to reference to particular VNF packages in a - filter. They should not be used both in the same filter instance, - but one alternative should be chosen. + See note 2. type: array items: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier" @@ -562,10 +558,7 @@ definitions: May be present if the "notificationTypes" attribute contains the value "VnfPackageChangeNotification" and shall be absent otherwise. - The attributes "vnfProductsFromProviders", "vnfdId" and "vnfPkgId" - are alternatives to reference to particular VNF packages in a - filter. They should not be used both in the same filter instance, - but one alternative should be chosen. + See note 2. type: array items: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier" diff --git a/src/SOL003/VNFSnapshotPackageManagement/definitions/SOL003VNFSnapshotPackageManagement_def.yaml b/src/SOL003/VNFSnapshotPackageManagement/definitions/SOL003VNFSnapshotPackageManagement_def.yaml index 7677c78f..24963fe4 100644 --- a/src/SOL003/VNFSnapshotPackageManagement/definitions/SOL003VNFSnapshotPackageManagement_def.yaml +++ b/src/SOL003/VNFSnapshotPackageManagement/definitions/SOL003VNFSnapshotPackageManagement_def.yaml @@ -4,7 +4,10 @@ definitions: VnfSnapshotPkgInfo: description: > - This type represents the information of a VNF snapshot package. + This type represents the information of a VNF snapshot package. It shall comply with the provisions defined in table 12.5.2.2-1. + + NOTE: The attribute shall not be present before the VNF snapshot package content has been uploaded or built. Otherwise, this + attribute shall be present unless it has been requested to be excluded per attribute selector. type: object required: - id @@ -25,9 +28,7 @@ definitions: a globally unique way. It is created during the "build VNF snapshot package operation". Multiples instances of the same VNF snapshot package share the same vnfSnapshotPkgUniqueId. - NOTE: The attribute shall not be present before the VNF snapshot package content - has been uploaded or built. Otherwise, this attribute shall be present unless it - has been requested to be excluded per attribute selector. + See note. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Identifier" name: description: > @@ -38,17 +39,13 @@ definitions: Checksum of the stored VNF snapshot package. Hash algorithms applicable to VNF snapshot packages are defined in ETSI GS NFV-SOL 010. - NOTE: The attribute shall not be present before the VNF snapshot package content - has been uploaded or built. Otherwise, this attribute shall be present unless it - has been requested to be excluded per attribute selector. + See note. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/Checksum" createdAt: description: > Timestamp indicating when the VNF snapshot package creation has been completed. - NOTE: The attribute shall not be present before the VNF snapshot package content - has been uploaded or built. Otherwise, this attribute shall be present unless it - has been requested to be excluded per attribute selector. + See note. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/DateTime" vnfSnapshotId: description: > @@ -61,9 +58,7 @@ definitions: of the VNF snapshot and contained in the VNF snapshot package. This identifier is allocated by the VNFM during the VNF snapshot creation. - NOTE: The attribute shall not be present before the VNF snapshot package content - has been uploaded or built. Otherwise, this attribute shall be present unless it - has been requested to be excluded per attribute selector. + See note. type: object items: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierLocal" @@ -86,9 +81,7 @@ definitions: Information about VNF snapshot artifacts that are VNFC snapshot images. Every local and external snapshot image shall be included. No other artifacts shall be included. - NOTE: The attribute shall not be present before the VNF snapshot package content - has been uploaded or built. Otherwise, this attribute shall be present unless it - has been requested to be excluded per attribute selector. + See note. type: object items: $ref: "#/definitions/VnfcSnapshotImageInfo" @@ -96,9 +89,7 @@ definitions: description: > Information about VNF snapshot artifacts that are not VNFC snapshot images. - NOTE: The attribute shall not be present before the VNF snapshot package content - has been uploaded or built. Otherwise, this attribute shall be present unless it - has been requested to be excluded per attribute selector. + See note. type: object items: $ref: "#/definitions/SnapshotPkgArtifactInfo" @@ -187,8 +178,13 @@ definitions: VnfcSnapshotImageInfo: description: > - This type represents an artifact contained in a VNF snapshot package which - represents a snapshot image. + This type represents an artifact contained in a VNF snapshot package which represents a snapshot image. + It shall comply with the provisions defined in table 12.5.3.2-1. + + NOTE 1: The list of permitted values was taken from "Container formats" in OpenStack® documentation: "Disk and container formats for images" + (Available at https://docs.openstack.org/glance/pike/user/formats.html). + NOTE 2: The list of permitted values was adapted from "Disk formats" in OpenStack® documentation: "Disk and container formats for images" + (Available at https://docs.openstack.org/glance/pike/user/formats.html). type: object required: - id @@ -212,7 +208,7 @@ definitions: - for an image artifact corresponding to a storage snapshot resource, the value is copied from the "storageResourceId" attribute in the "VnfcSnapshotInfo" of the corresponding storage snapshot resource. When onboarding an existing VNF snapshot package, the NFVO shall set the value of this attribute as provided - in the manifest file in the VNF snapshot package (refer to ETSI GS NFV-SOL 010 [i.14]). + in the manifest file in the VNF snapshot package (refer to ETSI GS NFV-SOL 010). $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierLocal" name: description: > @@ -245,8 +241,7 @@ definitions: - OVA: OVF package in a tarfile - OVF: OVF container format - NOTE: The list of permitted values was taken from "Container formats" in [i.5] - (OpenStack® documentation: "Disk and container formats for images"). + See note 1. type: string enum: - AKI @@ -272,8 +267,7 @@ definitions: - VHDX: enhanced version of VHD format - VMDK: a common disk image format - NOTE: The list of permitted values was adapted from "Disk formats" in [i.5] - (OpenStack® documentation: "Disk and container formats for images"). + See note 2. type: string enum: - AKI diff --git a/src/definitions/SOL002SOL003VNFFaultManagement_def.yaml b/src/definitions/SOL002SOL003VNFFaultManagement_def.yaml index 8ba60530..88dcbf32 100644 --- a/src/definitions/SOL002SOL003VNFFaultManagement_def.yaml +++ b/src/definitions/SOL002SOL003VNFFaultManagement_def.yaml @@ -256,13 +256,15 @@ definitions: FmNotificationsFilter: description: > - This type represents a subscription filter related to notifications - about VNF faults. - At a particular nesting level in the filter structure, the following - applies: All attributes shall match in order for the filter to match - (logical "and" between different filter attributes). If an attribute is - an array, the attribute shall match if at least one of the values in the - array matches (logical "or" between the values of one filter attribute). + This type represents a subscription filter related to notifications about VNF faults. + It shall comply with the provisions defined in table 7.5.3.2-1. + At a particular nesting level in the filter structure, the following applies: All attributes + shall match in order for the filter to match (logical "and" between different filter attributes). + If an attribute is an array, the attribute shall match if at least one of the values in the array + matches (logical "or" between the values of one filter attribute). + + NOTE: The permitted values of the "notificationTypes" attribute are spelled exactly as the names + of the notification types to facilitate automated code generation systems. type: object properties: vnfInstanceSubscriptionFilter: @@ -271,14 +273,13 @@ definitions: $ref: "SOL002SOL003_def.yaml#/definitions/VnfInstanceSubscriptionFilter" notificationTypes: description: > - Match particular notification types. + Match particular notification types. + Permitted values: - * AlarmNotification - * AlarmClearedNotification - * AlarmListRebuiltNotification - The permitted values of the "notificationTypes" attribute are - spelled exactly as the names of the notification types to - facilitate automated code generation systems. + - AlarmNotification + - AlarmClearedNotification + - AlarmListRebuiltNotification + See note. type: array items: type: string diff --git a/src/definitions/SOL002SOL003VNFIndicator_def.yaml b/src/definitions/SOL002SOL003VNFIndicator_def.yaml index 978c3500..14ed7fdc 100644 --- a/src/definitions/SOL002SOL003VNFIndicator_def.yaml +++ b/src/definitions/SOL002SOL003VNFIndicator_def.yaml @@ -4,7 +4,9 @@ definitions: VnfIndicator: description: > - This type represents a VNF indicator value. + This type represents a VNF indicator value. It shall comply with the provisions defined in table 8.5.2.2-1. + + NOTE: ETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. type: object required: - id @@ -23,10 +25,7 @@ definitions: type: string value: description: > - Provides the value of the indicator. The value format is defined in - the VNFD. - ETSI GS NFV-SOL 001 specifies the structure and format of the - VNFD based on TOSCA specifications. + Provides the value of the indicator. The value format is defined in the VNFD. See note. type: object vnfInstanceId: description: > @@ -51,13 +50,15 @@ definitions: VnfIndicatorNotificationsFilter: description: > - This type represents a subscription filter for notifications - related to VNF indicators. - At a particular nesting level in the filter structure, the following - applies: All attributes shall match in order for the filter to match - (logical "and" between different filter attributes). If an attribute is - an array, the attribute shall match if at least one of the values in the - array matches (logical "or" between the values of one filter attribute). + This type represents a subscription filter for notifications related to VNF indicators. + It shall comply with the provisions defined in table 8.5.3.2-1. + At a particular nesting level in the filter structure, the following applies: + All attributes shall match in order for the filter to match (logical "and" between different + filter attributes). If an attribute is an array, the attribute shall match if at least one of + the values in the array matches (logical "or" between the values of one filter attribute). + + NOTE: The permitted values of the "notificationTypes" attribute are spelled exactly as the names + of the notification types to facilitate automated code generation systems. type: object properties: vnfInstanceSubscriptionFilter: @@ -66,13 +67,12 @@ definitions: $ref: "SOL002SOL003_def.yaml#/definitions/VnfInstanceSubscriptionFilter" notificationTypes: description: > - Match particular notification types. + Match particular notification types. + Permitted values: - * VnfIndicatorValueChangeNotification - * SupportedIndicatorsChangeNotification - The permitted values of the "notificationTypes" attribute are spelled exactly - as the names of the notification types to facilitate automated code generation - systems. + - VnfIndicatorValueChangeNotification + - SupportedIndicatorsChangeNotification + See note. type: string enum: - VnfIndicatorValueChangeNotification @@ -152,9 +152,10 @@ definitions: VnfIndicatorValueChangeNotification: description: > - This type represents a VNF indicator value change notification. - The notification shall be triggered by the VNFM when the value of an - indicator has changed. + This type represents a VNF indicator value change notification. It shall comply with the provisions defined in table 8.5.2.5-1. + The notification shall be triggered by the VNFM when the value of an indicator has changed. + + NOTE: ETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. type: object required: - id @@ -198,10 +199,7 @@ definitions: type: string value: description: > - Provides the value of the VNF indicator. The value format is defined - in the VNFD. - ETSI GS NFV-SOL 001 specifies the structure and format of the VNFD - based on TOSCA specifications. + Provides the value of the VNF indicator. The value format is defined in the VNFD. See note. type: object vnfInstanceId: description: > @@ -229,9 +227,12 @@ definitions: description: > This type represents a notification to inform the receiver that the set of indicators supported by a VNF instance has changed. It shall comply with the provisions defined in table 8.5.2.6-1. + The notification shall be triggered by the VNFM when the set of supported VNF indicators has changed as a side effect of the "Change current VNF package" operation. It may be triggered by the VNFM when a VNF has been instantiated. + + NOTE: ETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications. type: object required: - id @@ -281,10 +282,7 @@ definitions: $ref: "SOL002SOL003_def.yaml#/definitions/IdentifierInVnfd" name: description: > - Human readable name of the VNF indicator. - Shall be present if defined in the VNFD. - ETSI GS NFV-SOL 001 specifies the structure and format of - the VNFD based on TOSCA specifications. + Human readable name of the VNF indicator. Shall be present if defined in the VNFD. See note. type: string _links: description: > diff --git a/src/definitions/SOL002SOL003VNFLifecycleManagement_def.yaml b/src/definitions/SOL002SOL003VNFLifecycleManagement_def.yaml index 211a00a9..4e508d99 100644 --- a/src/definitions/SOL002SOL003VNFLifecycleManagement_def.yaml +++ b/src/definitions/SOL002SOL003VNFLifecycleManagement_def.yaml @@ -65,8 +65,12 @@ definitions: ScaleVnfToLevelRequest: description: > - This type represents request parameters for the "Scale VNF to Level" - operation. + This type represents request parameters for the "Scale VNF to Level" operation. + It shall comply with the provisions defined in table 5.5.2.6-1. See clause B.2 + for an explanation of VNF scaling. + + NOTE: Either the instantiationLevelId attribute or the scaleInfo attribute shall + be included. type: object anyOf: - oneOf: @@ -79,15 +83,13 @@ definitions: description: > Identifier of the target instantiation level of the current deployment flavour to which the VNF is requested to be scaled. - Either the instantiationLevelId attribute or the scaleInfo attribute - shall be included. + See note. $ref: "SOL002SOL003_def.yaml#/definitions/IdentifierInVnfd" scaleInfo: description: > For each scaling aspect of the current deployment flavour, indicates the target scale level to which the VNF is to be scaled. - Either the instantiationLevelId attribute or the scaleInfo attribute - shall be included. + See note. type: array items: $ref: "#/definitions/ScaleInfo" @@ -241,6 +243,15 @@ definitions: $ref: "SOL002SOL003_def.yaml#/definitions/Link" ExtVirtualLinkInfo: + description: > + This type represents information about an external VL. It shall comply with the provisions defined in table 5.5.3.2-1. + + NOTE: This attribute reflects the current configuration information that has resulted from merging into this attribute + the "VnfExtCpData" information which was passed as part of the "ExtVirtualLinkData" structure in the input of the + most recent VNF LCM operation such as "InstantiateVnfRequest", "ChangeExtVnfConnectivityRequest", "ChangeVnfFlavourRequest" + or "ChangeCurrentVnfPkgRequest", or in the Grant response. If applying such change results in an empty list of + "currentVnfExtCpData" structure instances, the affected instance of "ExtVirtualLinkInfo" shall be removed from its + parent data structure. type: object required: - id @@ -266,14 +277,8 @@ definitions: $ref: "#/definitions/ExtLinkPortInfo" currentVnfExtCpData: description: > - Allows the API consumer to read the current CP configuration information for the connection of external CPs - to the external virtual link. - This attribute reflects the current configuration information that has resulted from merging into this attribute - the "VnfExtCpData" information which was passed as part of the "ExtVirtualLinkData" structure in the input of - the most recent VNF LCM operation such as "InstantiateVnfRequest", "ChangeExtVnfConnectivityRequest", - "ChangeVnfFlavourRequest" or "ChangeCurrentVnfPkgRequest", or has been provided by the NFVO during the granting - procedure. If applying such change results in an empty list of "currentVnfExtCpData" structure instances, the - affected instance of "ExtVirtualLinkInfo" shall be removed from its parent data structure. + Allows the API consumer to read the current CP configuration information for the connection of external CPs + to the external virtual link. See note. type: array items: $ref: "SOL002SOL003_def.yaml#/definitions/VnfExtCpData" @@ -301,6 +306,19 @@ definitions: type: integer VnfLinkPortInfo: + description: > + This type represents a link port of an internal VL of a VNF. It shall comply with the provisions + defined in table 5.5.3.8 1. + + NOTE 1: Either cpInstanceId with cpInstanceType set to "EXT_CP" or any combination of cpInstanceId + with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be + present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" + and vipCpInstanceId are present, the two different CP instances share the linkport. + NOTE 2: Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId + and vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or + only vipCpInstanceId is present (UC6 and UC#6-b). + NOTE 3: The value of "trunkResourceId" is scoped by the value of "vimConnectionId" in the "resourceHandle" + attribute. type: object required: - id @@ -317,65 +335,51 @@ definitions: $ref: "SOL002SOL003_def.yaml#/definitions/ResourceHandle" cpInstanceId: description: > - When the link port is used for external connectivity by the VNF, - this attribute represents the identifier of the external CP of the - VNF to be connected to this link port. - When the link port is used for internal connectivity in the VNF, - this attribute represents the identifier of the VNFC CP to be connected to this link - port. - Shall be present when the link port is used for external - connectivity by the VNF. + When the link port is used for external connectivity by the VNF, this attribute represents the + identifier of the external CP associated with this link port. + + When the link port is used for internal connectivity in the VNF, this attribute represents the + identifier of the VNFC CP to be connected to this link port. + + Shall be present when the link port is used for external connectivity by the VNF. May be present if used to reference a VNFC CP instance. - There shall be at most one link port associated with any external - connection point instance or internal connection point - (i.e. VNFC CP) instance. - The value refers to an "extCpInfo" item in the VnfInstance or a - "vnfcCpInfo" item of a "vnfcResourceInfo" item in the VnfInstance. - Either cpInstanceId with cpInstanceType set to "EXT_CP" or any combination of cpInstanceId - with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall - be present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" - and vipCpInstanceId are present, the two different CP instances share the linkport. + There shall be at most one link port associated with any external connection point instance or + internal connection point (i.e. VNFC CP) instance. + The value refers to an "extCpInfo" item in the VnfInstance or a "vnfcCpInfo" item of a "vnfcResourceInfo" + item in the VnfInstance. See note 1. $ref: "SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" cpInstanceType: description: > - Type of the CP instance that is identified by cpInstanceId. - Shall be present if "cpInstanceId" is present, and shall be absent otherwise. + Type of the CP instance that is identified by cpInstanceId. + Shall be present if "cpInstanceId" is present and shall be absent otherwise. + Permitted values: - VNFC_CP: The link port is connected to a VNFC CP - EXT_CP: The link port is associated to an external CP. - Either cpInstanceId with cpInstanceType set to "EXT_CP" or any combination of cpInstanceId - with cpInstanceType set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall - be present for a VnfLinkPortInfo. In case both cpInstanceId with cpInstanceType set to "VNFC_CP" - and vipCpInstanceId are present, the two different CP instances share the linkport. + - VNFC_CP: The link port is connected to a VNFC CP. + - EXT_CP: The link port is associated to an external CP. + See note 1. type: string enum: - VNFC_CP - EXT_CP - vipCpInstanceId: description: > - VIP CP instance of the VNF connected to this link port. May be present. - Either cpInstanceId with cpInstanceType set to "EXT_CP" or any combination of cpInstanceId with cpInstanceType - set to "VNFC_CP" and vipCpInstanceId (i.e. one or both of them) shall be present for a VnfLinkPortInfo. - In case both cpInstanceId with cpInstanceType set to "VNFC_CP" and vipCpInstanceId are present, the two - different CP instances share the linkport. - Annex A.4 of ETSI GS NFV-IFA 007 provides examples for configurations where both vipCpInstanceId and - vnfcCpInstanceId are present (UC#5 and UC#5-b), only vnfcCpInstanceId is present (UC#2), or only - vipCpInstanceId is present (UC6 and UC#6-b). + VIP CP instance of the VNF connected to this link port. May be present. + See notes 1, and 2. $ref: "SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" - trunkResourceId: description: > Identifier of the trunk resource in the VIM. - Shall be present if the present link port corresponds to the parent port that the trunk resource is associated with. - The value of "trunkResourceId" is scoped by the value of "vimConnectionId" in the "resourceHandle" attribute. + Shall be present if the present link port corresponds to the parent port that the trunk resource is associated with. + See note 3. $ref: "SOL002SOL003_def.yaml#/definitions/IdentifierInVim" - ExtLinkPortInfo: description: > - This type represents information about a link port of an external VL, - i.e. a port providing connectivity for the VNF to an NS VL. + This type represents information about a link port of an external VL, i.e. a port providing connectivity for the VNF to + an NS VL. It shall comply with the provisions defined in table 5.5.3.9-1. + + NOTE 1: The use cases UC#4 and UC#5 in Annex A.4 of ETSI GS NFV-IFA 007 provide examples for such a configuration. + NOTE 2: The value of "trunkResourceId" is scoped by the value of "vimConnectionId" in the "resourceHandle" attribute. type: object required: - id @@ -398,47 +402,38 @@ definitions: external connection point instance. The value refers to an "extCpInfo" item in the VnfInstance. $ref: "SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" - secondaryCpInstanceId: description: > Additional external CP of the VNF connected to this link port. - If present, this attribute shall refer to a "secondary" ExtCpInfo - item in the VNF instance that exposes a virtual IP CP instance which - shares this linkport with the external CP instance referenced by the - "cpInstanceId" attribute. - The use cases UC#4 and UC#5 in Annex A.4 of ETSI GS NFV-IFA 007 - provide examples for such a configuration. - + If present, this attribute shall refer to a "secondary" ExtCpInfo item in the VNF instance that exposes a virtual + IP CP instance which shares this linkport with the external CP instance referenced by the "cpInstanceId" attribute. + See note 1. $ref: "SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" - trunkResourceId: description: > - Identifier of the trunk resource in the VIM. - Shall be present if the present link port corresponds - to the parent port that the trunk resource is associated with. - The value of "trunkResourceId" is scoped by the value of "vimConnectionId" - in the "resourceHandle" attribute - + Identifier of the trunk resource in the VIM. + Shall be present if the present link port corresponds to the parent port that the trunk resource is associated with. + See note 2. $ref: "SOL002SOL003_def.yaml#/definitions/IdentifierInVim" - CpProtocolInfo: description: > - This type describes the protocol layer(s) that a CP uses together with - protocol-related information, like addresses. + This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses. + It shall comply with the provisions defined in table 5.5.3.9b-1. + + NOTE: This attribute allows to signal the addition of further types of layer and protocol in future versions of the + present document in a backwards-compatible way. In the current version of the present document, only IP over + Ethernet is supported. type: object required: - layerProtocol properties: layerProtocol: description: > - The identifier of layer(s) and protocol(s) associated to the network - address information. + The identifier of layer(s) and protocol(s) associated to the network address information. + Permitted values: IP_OVER_ETHERNET - This attribute allows to signal the addition of further types of - layer and protocol in future versions of the present document in a - backwards-compatible way. In the current version of the present - document, only IP over Ethernet is supported. + See note. type: string enum: - IP_OVER_ETHERNET @@ -451,8 +446,19 @@ definitions: IpOverEthernetAddressInfo: description: > - This type represents information about a network address that has been - assigned. + This type represents information about a network address that has been assigned. + It shall comply with the provisions defined in table 5.5.3.10-1. + + NOTE 1: At least one of "macAddress" or "ipAddresses" shall be present. + NOTE 2: Exactly one of "addresses" or "addressRange" shall be present. + NOTE 3: If the Cp instance represents a subport in a trunk, segmentationId shall be present. + Otherwise it shall not be present. + NOTE 4: Depending on the NFVI networking infrastructure, the segmentationId may indicate the + actual network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the + transport header of the packets or it may be an identifier used between the application + and the NFVI networking infrastructure to identify the network sub-interface of the trunk + port in question. In the latter case the NFVI infrastructure will map this local segmentationId + to whatever segmentationId is actually used by the NFVI’s transport technology. type: object anyOf: - required: @@ -467,25 +473,16 @@ definitions: properties: macAddress: description: > - MAC address, if assigned. - At least one of "macAddress" or "ipAddresses" shall be present. + MAC address, if assigned. See note 1. $ref: "SOL002SOL003_def.yaml#/definitions/MacAddress" segmentationId: description: > - Identification of the network segment to which the Cp instance connects to. If the Cp instance represents a - subport in a trunk, segmentationId shall be present. Otherwise it shall not be present. - Depending on the NFVI networking infrastructure, the segmentationId may indicate the actual network segment - value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header of the packets or it may be an - identifier used between the application and the NFVI networking infrastructure to identify the network - sub-interface of the trunk port in question. In the latter case the NFVI infrastructure will map this local - segmentationId to whatever segmentationId is actually used by the NFVI’s transport technology. + Identification of the network segment to which the Cp instance connects to. See notes 3 and 4. type: string ipAddresses: description: > - Addresses assigned to the CP instance. Each entry represents IP - addresses assigned by fixed or dynamic IP address assignment per - subnet. - At least one of "macAddress" or "ipAddresses" shall be present. + Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or + dynamic IP address assignment per subnet. See note 1. type: array items: type: object @@ -502,9 +499,7 @@ definitions: - IPV6 addresses: description: > - Fixed addresses assigned (from the subnet defined by - "subnetId" if provided). - Exactly one of "addresses" or "addressRange" shall be present. + Fixed addresses assigned (from the subnet defined by "subnetId" if provided). See note 2. type: array items: $ref: "SOL002SOL003_def.yaml#/definitions/IpAddress" @@ -517,8 +512,7 @@ definitions: type: boolean addressRange: description: > - An IP address range used, e.g., in case of egress connections. - Exactly one of "addresses" or "addressRange" shall be present. + An IP address range used, e.g. in case of egress connections. See note 2. type: object required: - minAddress @@ -569,14 +563,15 @@ definitions: LifecycleChangeNotificationsFilter: description: > - This type represents a subscription filter related to notifications - about VNF lifecycle changes. - At a particular nesting level in the filter structure, the following - applies: All attributes shall match in order for the filter to match - (logical "and" between different filter attributes). If an attribute is - an array, the attribute shall match if at least one of the values in - the array matches (logical "or" between the values of one filter - attribute). + This type represents a subscription filter related to notifications about VNF lifecycle changes. + It shall comply with the provisions defined in table 5.5.3.12-1. + At a particular nesting level in the filter structure, the following applies: All attributes shall + match in order for the filter to match (logical "and" between different filter attributes). + If an attribute is an array, the attribute shall match if at least one of the values in the array + matches (logical "or" between the values of one filter attribute). + + NOTE: The permitted values of the "notificationTypes" attribute are spelled exactly as the names of + the notification types to facilitate automated code generation systems. type: object properties: vnfInstanceSubscriptionFilter: @@ -585,14 +580,13 @@ definitions: $ref: "SOL002SOL003_def.yaml#/definitions/VnfInstanceSubscriptionFilter" notificationTypes: description: > - Match particular notification types. + Match particular notification types. + Permitted values: - * VnfLcmOperationOccurrenceNotification - * VnfIdentifierCreationNotification - * VnfIdentifierDeletionNotification - The permitted values of the "notificationTypes" attribute are - spelled exactly as the names of the notification types to - facilitate automated code generation systems. + - VnfLcmOperationOccurrenceNotification + - VnfIdentifierCreationNotification + - VnfIdentifierDeletionNotification + See note. type: array items: type: string @@ -648,8 +642,13 @@ definitions: VnfExtCpInfo: description: > - This type represents information about an external CP of a VNF. - It shall comply with the provisions defined in table 5.5.3.25 1. + This type represents information about an external CP of a VNF. + It shall comply with the provisions defined in table 5.5.3.17 1. + + NOTE 1: The attributes "associatedVnfcCpId", "associatedVipCpId" and "associatedVnfVirtualLinkId" + are mutually exclusive. Exactly one shall be present. + NOTE 2: An external CP instance is not associated to a link port in the cases indicated for the + “extLinkPorts” attribute in clause 4.4.1.11. type: object required: - id @@ -691,9 +690,8 @@ definitions: $ref: "#/definitions/CpProtocolInfo" extLinkPortId: description: > - Identifier of the "ExtLinkPortInfo" structure inside the "ExtVirtualLinkInfo" structure. - Shall be present if the CP is associated to a link port. An external CP instance is not associated - to a link port in the cases indicated for the “extLinkPorts” attribute in clause 4.4.1.11. + Identifier of the "ExtLinkPortInfo" structure inside the "ExtVirtualLinkInfo" structure. + Shall be present if the CP is associated to a link port. See note 2. $ref: "SOL002SOL003_def.yaml#/definitions/Identifier" metadata: description: > @@ -701,28 +699,22 @@ definitions: $ref: "SOL002SOL003_def.yaml#/definitions/KeyValuePairs" associatedVnfcCpId: description: > - Identifier of the "vnfcCpInfo" structure in "VnfcResourceInfo" structure that represents - the VNFC CP which is exposed by this external CP instance, either directly or via a floating IP address. - Shall be present in case this CP instance maps to a VNFC CP. - The attributes "associatedVnfcCpId", "associatedVipCpId" and "associatedVnfVirtualLinkId" are mutually - exclusive. Exactly one shall be present. + Identifier of the "vnfcCpInfo" structure in "VnfcResourceInfo" structure that represents the VNFC CP + which is exposed by this external CP instance, either directly or via a floating IP address. + Shall be present in case this CP instance maps to a VNFC CP. See note 1. $ref: "SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" associatedVipCpId: description: > - Identifier of the VIP CP instance that is exposed as this VnfExtCp instance, either directly or via - a floating IP address, and the related "VipCpInfo" structure in "VnfInstance". Shall be present if - the cpdId of this VnfExtCp has a vipCpd attribute. - The attributes "associatedVnfcCpId", "associatedVipCpId" and "associatedVnfVirtualLinkId" - are mutually exclusive. Exactly one shall be present. + Identifier of the VIP CP instance that is exposed as this VnfExtCp instance, either directly or via a + floating IP address, and the related "VipCpInfo" structure in "VnfInstance". Shall be present if the + cpdId of this VnfExtCp has a vipCpd attribute. See note 1. $ref: "SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" associatedVnfVirtualLinkId: description: > - Identifier of the "VnfVirtualLinkResourceInfo" structure that represents the internal VL - or of the "ExtManagedVirtualLinkInfo" structure that represents the externally-managed internal VL - which is exposed by this external CP instance. Shall be present in case this CP instance maps to an - internal VL (including externally-managed internal VL). - The attributes "associatedVnfcCpId", "associatedVipCpId" and "associatedVnfVirtualLinkId" are mutually - exclusive. Exactly one shall be present. + Identifier of the "VnfVirtualLinkResourceInfo" structure that represents the internal VL or of the + "ExtManagedVirtualLinkInfo" structure that represents the externally-managed internal VL which is + exposed by this external CP instance. Shall be present in case this CP instance maps to an internal + VL (including externally-managed internal VL). See note 1. $ref: "SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" VnfOperationalStateType: @@ -949,37 +941,36 @@ definitions: ModificationsTriggeredByVnfPkgChange: description: > - This type represents attribute modifications that were performed on an "Individual VNF instance" resource when - changing the current VNF package. The attributes that can be included consist of those requested to be modified - explicitly in the "ChangeCurrentVnfPkgRequest" data structure, and additional attributes of the "VnfInstance" - data structure that were modified implicitly during the operation. + This type represents attribute modifications that were performed on an "Individual VNF instance" resource + when changing the current VNF package. The attributes that can be included consist of those requested to + be modified explicitly in the "ChangeCurrentVnfPkgRequest" data structure, and additional attributes of the + "VnfInstance" data structure that were modified implicitly during the operation. + The "ModificationsTriggeredByVnfPkgChange" data type shall comply with the provisions defined in table 5.5.3.21-1. + + NOTE 1: This attribute represents the delta (semantics as per IETF RFC 7396, JSON Merge Patch) between the value + of the attribute at the start of the "Change current VNF package" operation and the value of the attribute + at its completion. + NOTE 2: If present, this attribute (which depends on the value of the "vnfdId" attribute) was modified implicitly + during the related operation and contains a copy of the value of the related attribute from the VNFD in the + VNF Package identified by the "vnfdId" attribute. type: object properties: vnfConfigurableProperties: description: > - This attribute signals the modifications of the "vnfConfigurableProperties" attribute in "VnfInstance" performed - by the operation and shall be present if that attribute was modified during the operation. + This attribute signals the modifications of the "vnfConfigurableProperties" attribute in "VnfInstance" performed + by the operation and shall be present if that attribute was modified during the operation. See note 1. In addition, the provisions in clause 5.7 shall apply. - This attribute represents the delta (semantics as per IETF RFC 7386, JSON Merge Patch) between the value - of the attribute at the start of the "Change current VNF package" operation and the value of the attribute at - its completion. $ref: "SOL002SOL003_def.yaml#/definitions/KeyValuePairs" metadata: description: > - This attribute signals the modifications of the "metadata" attribute in "VnfInstance" performed by the operation - and shall be present if that attribute was modified during the operation. - This attribute represents the delta (semantics as per IETF RFC 7386, JSON Merge Patch) between the value - of the attribute at the start of the "Change current VNF package" operation and the value of the attribute at - its completion. + This attribute signals the modifications of the "metadata" attribute in "VnfInstance" performed by the operation and + shall be present if that attribute was modified during the operation. See note 1. $ref: "SOL002SOL003_def.yaml#/definitions/KeyValuePairs" extensions: description: > - This attribute signals the modifications of the "extensions" attribute in "VnfInstance" performed by the operation and - shall be present if that attribute was modified during the operation. + This attribute signals the modifications of the "extensions" attribute in "VnfInstance" performed by the operation and + shall be present if that attribute was modified during the operation. See note 1. In addition, the provisions in clause 5.7 shall apply. - This attribute represents the delta (semantics as per IETF RFC 7386, JSON Merge Patch) between the value - of the attribute at the start of the "Change current VNF package" operation and the value of the attribute at - its completion. $ref: "SOL002SOL003_def.yaml#/definitions/KeyValuePairs" vnfdId: description: > @@ -987,31 +978,19 @@ definitions: $ref: "SOL002SOL003_def.yaml#/definitions/Identifier" vnfProvider: description: > - If present, this attribute signals the new value of the "vnfProvider" attribute in "VnfInstance". If present, - this attribute (which depends on the value of the "vnfdId" attribute) was modified implicitly during the related - operation, and contains a copy of the value of he related attribute from the VNFD in the VNF Package identified - by the "vnfdId" attribute. + If present, this attribute signals the new value of the "vnfProvider" attribute in "VnfInstance". See note 2. type: string vnfProductName: description: > - If present, this attribute signals the new value of the "vnfProductName" attribute in "VnfInstance". If present, - this attribute (which depends on the value of the "vnfdId" attribute) was modified implicitly during the related - operation, and contains a copy of the value of he related attribute from the VNFD in the VNF Package identified - by the "vnfdId" attribute. + If present, this attribute signals the new value of the "vnfProductName" attribute in "VnfInstance". See note 2. type: string vnfSoftwareVersion: description: > - If present, this attribute signals the new value of the "vnfSoftwareVersion" attribute in "VnfInstance". If present, - this attribute (which depends on the value of the "vnfdId" attribute) was modified implicitly during the related - operation, and contains a copy of the value of he related attribute from the VNFD in the VNF Package identified - by the "vnfdId" attribute. + If present, this attribute signals the new value of the "vnfSoftwareVersion" attribute in "VnfInstance". See note 2. $ref: "SOL002SOL003_def.yaml#/definitions/Version" vnfdVersion: description: > - If present, this attribute signals the new value of the "vnfdVersion" attribute in "VnfInstance". If present, - this attribute (which depends on the value of the "vnfdId" attribute) was modified implicitly during the related - operation, by copying the value of this attribute from the VNFD in the VNF Package identified by the "vnfdId" - attribute. + If present, this attribute signals the new value of the "vnfdVersion" attribute in "VnfInstance". See note 2. $ref: "SOL002SOL003_def.yaml#/definitions/Version" LcmOpOccNotificationVerbosityType: @@ -1067,13 +1046,11 @@ definitions: - REMOVED - MODIFIED - - - - VipCpInfo: description: > - This type provides information related to virtual IP (VIP) CP. + This type provides information related to virtual IP (VIP) CP. It shall comply with the provisions defined in table 5.5.3.22-1. + + NOTE: It is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. type: object required: - cpInstanceId @@ -1083,17 +1060,14 @@ definitions: description: > Identifier of this VIP CP instance and of this VipCpInfo information element. $ref: "SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" - cpdId: description: > Identifier of the VIP Connection Point Descriptor, VipCpd, in the VNFD. $ref: "SOL002SOL003_def.yaml#/definitions/IdentifierInVnfd" - vnfExtCpId: description: > When the VIP CP is exposed as external CP of the VNF, the identifier of this external VNF CP instance. $ref: "SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" - cpProtocolInfo: description: > Protocol information for this CP. There shall be one cpProtocolInfo for layer 3. @@ -1101,25 +1075,21 @@ definitions: type: array items: $ref: "#/definitions/CpProtocolInfo" - associatedVnfcCpIds: description: > - Identifiers of the VnfcCps that share the virtual IP addresses allocated to the VIP CP instance. - It is possible that there is no associated VnfcCp because the VIP CP is available but not associated yet. + Identifiers of the VnfcCps that share the virtual IP addresse allocated to the VIP CP instance. See note. type: array items: $ref: "SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" - vnfLinkPortId: description: > Identifier of the "VnfLinkPortInfo" structure in the "VnfVirtualLinkResourceInfo" or "ExtManagedVirtualLinkInfo" structure. Shall be present if the CP is associated to a link port on an internal VL (including externally-managed internal VL). $ref: "SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" - metadata: description: > Metadata about this VIP CP. type: array items: - $ref: "SOL002SOL003_def.yaml#/definitions/KeyValuePairs" + $ref: "SOL002SOL003_def.yaml#/definitions/KeyValuePairs" \ No newline at end of file diff --git a/src/definitions/SOL002SOL003VNFPerformanceManagement_def.yaml b/src/definitions/SOL002SOL003VNFPerformanceManagement_def.yaml index 52e47ec2..5a94574d 100644 --- a/src/definitions/SOL002SOL003VNFPerformanceManagement_def.yaml +++ b/src/definitions/SOL002SOL003VNFPerformanceManagement_def.yaml @@ -202,9 +202,17 @@ definitions: PerformanceReport: description: > - This type defines the format of a performance report provided by the VNFM to the EM as a result - of collecting performance information as part of a PM job. - The type shall comply with the provisions defined in table 6.5.2.10-1. + This type defines the format of a performance report provided by the VNFM to the NFVO as a result of collecting + performance information as part of a PM job. The type shall comply with the provisions defined in table 6.5.2.10-1. + + NOTE: The sub-object allows to structure the measured object but is not to be confused with sub-counters which allow + to structure the measurement value. + + EXAMPLE: + Measured object: VnfInstanceXYZ + Sub-object: VnfcInstance1 + Measurement: vCPU_utilization + Sub-counters: vCPU utilization of each of the vCPUs of VnfcInstance1 (vCPU utilization.vCPU1, vCPU_utilization.vCPU2, etc.). type: object required: - entries @@ -235,18 +243,9 @@ definitions: $ref: "SOL002SOL003_def.yaml#/definitions/Identifier" subObjectInstanceId: description: > - Identifier of the sub-object instance of the measured object (i.e. of the measured object instance) - for which the performance metric is reported. - Shall be present if this is required in clause 6.2 of ETSI GS NFV-IFA 027 - for the related measured object type. - The sub-object allows to structure the measured object but is not to be confused - with sub-counters which allow to structure the measurement value. - EXAMPLE: - Measured object: VnfInstanceXYZ - Sub-object: VnfcInstance1 - Measurement: vCPU_utilization - Sub-counters: vCPU utilization of each of the vCPUs of VnfcInstance1 - (vCPU_utilization.vCPU1, vCPU_utilization.vCPU2, etc.). + Identifier of the sub-object instance of the measured object instance for which the performance + metric is reported. Shall be present if this is required in clause 6.2 of ETSI GS NFV-IFA 027 + for the related measured object type. See note. $ref: "SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" performanceMetric: description: > @@ -384,8 +383,9 @@ definitions: PmJobModifications: description: > - This type represents modifications to a PM job. - It shall comply with the provisions defined in table 6.5.2.12-1. + This type represents modifications to a PM job. It shall comply with the provisions defined in table 6.5.2.12-1. + + NOTE: At least one of the attributes defined in this type shall be present in request bodies. type: object oneOf: - required: @@ -395,22 +395,27 @@ definitions: properties: callbackUri: description: > - New value of the "callbackUri" attribute. - The value "null" is not permitted. See note. + New value of the "callbackUri" attribute. The value "null" is not permitted. See note. $ref: "SOL002SOL003_def.yaml#/definitions/Uri" authentication: description: > - New value of the "authentication" attribute, or "null" - to remove the attribute. If present in a request body, - these modifications shall be applied according to the - rules of JSON Merge Patch (see IETF RFC 7396). - This attribute shall not be present in response bodies. - At least one of the attributes defined in this type shall be present in request bodies. + New value of the "authentication" attribute, or "null" to remove the attribute. If present + in a request body, these modifications shall be applied according to the rules of JSON Merge + Patch (see IETF RFC 7396). + + This attribute shall not be present in response bodies. See note. $ref: "SOL002SOL003_def.yaml#/definitions/SubscriptionAuthentication" PmJobCriteria: description: > - Criteria of the collection of performance information. + This type represents collection criteria for PM jobs. It shall comply with the provisions defined in table 6.5.3.3-1. + + NOTE 1: At the end of each reportingPeriod, the API producer will inform the API consumer about availability of the + performance data collected for each completed collection period during this reportingPeriod. + The reportingPeriod should be equal to or a multiple of the collectionPeriod. In the latter case, the performance + data for the collection periods within one reporting period are reported together. + NOTE 2: In particular when choosing short collection and reporting periods, the number of PM jobs that can be supported + depends on the capability of the producing entity. type: object required: - collectionPeriod @@ -437,15 +442,8 @@ definitions: type: string collectionPeriod: description: > - Specifies the periodicity at which the API producer will collect - performance information. The unit shall be seconds. - At the end of each reportingPeriod, the API producer will inform the - consumer about availability of the performance data collected for - each completed collection period during this reportingPeriod. The - reportingPeriod should be equal to or a multiple of the - collectionPeriod. In the latter case, the performance data for the - collection periods within one reporting period are reported - together. + SSpecifies the periodicity at which the API producer will collect performance information. + The unit shall be seconds. See notes 1 and 2. type: integer minimum: 0 maximum: 1024 @@ -453,15 +451,8 @@ definitions: # Done using min and max params to set a range for positive int. reportingPeriod: description: > - Specifies the periodicity at which the API producer will report to the - API consumer. about performance information. The unit shall be seconds. - At the end of each reportingPeriod, the API producer will inform the - API consumer about availability of the performance data collected for - each completed collection period during this reportingPeriod. The - reportingPeriod should be equal to or a multiple of the - collectionPeriod. In the latter case, the performance data for the - collection periods within one reporting period are reported - together. + Specifies the periodicity at which the API producer will report to the API consumer + about performance information. The unit shall be seconds. See notes 1 and 2. type: integer minimum: 0 maximum: 1024 @@ -541,8 +532,9 @@ definitions: ThresholdModifications: description: > - This type represents modifications to a threshold. - It shall comply with the provisions defined in table 6.5.2.11-1. + This type represents modifications to a threshold. It shall comply with the provisions defined in table 6.5.2.11-1. + + NOTE: At least one of the attributes defined in this type shall be present in request bodies. type: object oneOf: - required: @@ -552,22 +544,25 @@ definitions: properties: callbackUri: description: > - New value of the "callbackUri" attribute. - The value "null" is not permitted. See note. + New value of the "callbackUri" attribute. The value "null" is not permitted. See note. $ref: "SOL002SOL003_def.yaml#/definitions/Uri" authentication: description: > - New value of the "authentication" attribute, or "null" - to remove the attribute. If present in a request body, - these modifications shall be applied according to the - rules of JSON Merge PATCH (see IETF RFC 7396). - This attribute shall not be present in response bodies. - At least one of the attributes defined in this type shall be present in request bodies. + New value of the "authentication" attribute, or "null" to remove the attribute. If present + in a request body, these modifications shall be applied according to the rules of JSON Merge + Patch (see IETF RFC 7396). + This attribute shall not be present in response bodies. See note. $ref: "SOL002SOL003_def.yaml#/definitions/SubscriptionAuthentication" ThresholdCriteria: description: > - This type represents criteria that define a threshold. + This type represents criteria that define a threshold. It shall comply with the provisions defined in table 6.5.3.4-1. + + NOTE 1: In the present document, simple thresholds are defined. The definition of additional threshold types is left for + future specification. + NOTE 2: The hysteresis is defined to prevent storms of threshold crossing notifications. When processing a request to create + a threshold, implementations should enforce a suitable minimum value for this attribute (e.g. override the value or + reject the request). type: object required: - performanceMetric @@ -580,13 +575,11 @@ definitions: type: string thresholdType: description: > - Type of threshold. This attribute determines which other attributes - are present in the data structure. + Type of threshold. This attribute determines which other attributes are present in the data structure. + Permitted values: - * SIMPLE: Single-valued static threshold - In the present document, simple thresholds are defined. The - definition of additional threshold types is left for future - specification. + - SIMPLE: Single-valued static threshold. + See note 1. type: string enum: - SIMPLE @@ -609,18 +602,12 @@ definitions: format: float hysteresis: description: > - The hysteresis of the threshold. Shall be represented as a - non-negative floating point number. - A notification with crossing direction "UP" will be generated if - the measured value reaches or exceeds - "thresholdValue" + "hysteresis". A notification with crossing - direction "DOWN" will be generated if the measured value reaches - or undercuts "thresholdValue" - "hysteresis". - The hysteresis is defined to prevent storms of threshold - crossing notifications. When processing a request to create a - threshold, implementations should enforce a suitable minimum - value for this attribute (e.g. override the value or reject the - request). + The hysteresis of the threshold. + Shall be represented as a non-negative floating point number. + + A notification with crossing direction "UP" will be generated if the measured value reaches or exceeds + "thresholdValue" + "hysteresis". A notification with crossing direction "DOWN" will be generated if the + measured value reaches or undercuts "thresholdValue" - "hysteresis". See note 2. # TODO: This should be floating. # Done using Number type and floating format. type: number @@ -628,15 +615,18 @@ definitions: maximum: 1024 format: float - ThresholdCrossedNotification: description: > - This type represents a notification that is sent when a threshold has - been crossed. - The timing of sending this notification is determined by the capability - of the producing entity to evaluate the threshold crossing condition. - The notification shall be triggered by the VNFM when a threshold has - been crossed. + This type represents a notification that is sent when a threshold has been crossed. + It shall comply with the provisions defined in table 6.5.2.4-1. + + NOTE: The timing of sending this notification is determined by the capability of the + producing entity to evaluate the threshold crossing condition. + + The notification shall be triggered by the VNFM when a threshold has been crossed. + + NOTE: The sub-object allows to structure the measured object, but is not to be confused + with sub-counters which allow to structure the measurement. type: object required: - id @@ -687,11 +677,10 @@ definitions: $ref: "SOL002SOL003_def.yaml#/definitions/Identifier" subObjectInstanceId: description: > - Identifier of the sub-object of the measured object (i.e. a VNFC instance) - to which the measurement applies. - Shall be present if this is required in an external measurement specification. - The sub-object allows to structure the measured object, but is not to be confused - with sub-counters which allow to structure the measurement. + Identifier of the sub-object of the measured object to which the measurement applies. + Shall be present if this is required in clause 6.2 of ETSI GS NFV-IFA 027 for the related + measured object type. + See note. $ref: "SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" performanceMetric: description: > -- GitLab