From ea33841ebab68d9b4e1ea275d1c51bf2ba049768 Mon Sep 17 00:00:00 2001 From: muhammadh Date: Mon, 27 Jun 2022 12:19:53 +0500 Subject: [PATCH 1/2] Update SOL003 VNF Lifecycle Operation Granting API as per v3.6.1 --- .../Grants.robot | 14 ++-- .../IndividualGrant.robot | 14 ++-- .../schemas/grant.schema.json | 76 ++++++++++++------- 3 files changed, 61 insertions(+), 43 deletions(-) diff --git a/SOL003/VNFLifecycleOperationGranting-API/Grants.robot b/SOL003/VNFLifecycleOperationGranting-API/Grants.robot index 301b13039..d5a158b67 100644 --- a/SOL003/VNFLifecycleOperationGranting-API/Grants.robot +++ b/SOL003/VNFLifecycleOperationGranting-API/Grants.robot @@ -22,7 +22,7 @@ Requests a grant for a particular VNF lifecycle operation - Synchronous mode ... Test title: Requests a grant for a particular VNF lifecycle operation - Synchronous mode ... Test objective: The objective is to request a grant for a particular VNF lifecycle operation and perform a JSON schema validation on the returned grant data structure ... Pre-conditions: none - ... Reference: Clause 9.4.2.3.1 - ETSI GS NFV-SOL 003 [1] v3.5.1 + ... Reference: Clause 9.4.2.3.1 - ETSI GS NFV-SOL 003 [1] v3.6.1 ... Config ID: Config_prod_NFVO ... Applicability: The NFVO can decide immediately what to respond to a grant request ... Post-Conditions: The grant information is available to the VNFM. @@ -36,7 +36,7 @@ Requests a grant for a particular VNF lifecycle operation - Asynchronous mode ... Test title: Requests a grant for a particular VNF lifecycle operation - Asynchronous mode ... Test objective: The objective is to request a grant for a particular VNF lifecycle operation and perform a JSON schema validation on the returned grant data structure ... Pre-conditions: none - ... Reference: Clause 9.4.2.3.1 - ETSI GS NFV-SOL 003 [1] v3.5.1 + ... Reference: Clause 9.4.2.3.1 - ETSI GS NFV-SOL 003 [1] v3.6.1 ... Config ID: Config_prod_NFVO ... Applicability: The NFVO can not decide immediately what to respond to a grant request ... Post-Conditions: The grant information is available to the VNFM. @@ -51,7 +51,7 @@ Requests a grant for a particular VNF lifecycle operation - Forbidden ... Test title: Requests a grant for a particular VNF lifecycle operation - Forbidden ... Test objective: The objective is to request a grant for a particular VNF lifecycle operation and the grant is rejected ... Pre-conditions: none - ... Reference: Clause 9.4.2.3.1 - ETSI GS NFV-SOL 003 [1] v3.5.1 + ... Reference: Clause 9.4.2.3.1 - ETSI GS NFV-SOL 003 [1] v3.6.1 ... Config ID: Config_prod_NFVO ... Applicability: none ... Post-Conditions: none @@ -64,7 +64,7 @@ GET Grants - Method not implemented ... Test title: GET Grants - Method not implemented ... Test objective: The objective is to test that GET method is not allowed for Life cycle operation granting ... Pre-conditions: none - ... Reference: Clause 9.4.2.3.2 - ETSI GS NFV-SOL 003 [1] v3.5.1 + ... Reference: Clause 9.4.2.3.2 - ETSI GS NFV-SOL 003 [1] v3.6.1 ... Config ID: Config_prod_NFVO ... Applicability: none ... Post-Conditions: none @@ -76,7 +76,7 @@ PUT Grants - Method not implemented ... Test title: PUT Grants - Method not implemented ... Test objective: The objective is to test that PUT method is not allowed for Life cycle operation granting ... Pre-conditions: none - ... Reference: Clause 9.4.2.3.3 - ETSI GS NFV-SOL 003 [1] v3.5.1 + ... Reference: Clause 9.4.2.3.3 - ETSI GS NFV-SOL 003 [1] v3.6.1 ... Config ID: Config_prod_NFVO ... Applicability: none ... Post-Conditions: none @@ -88,7 +88,7 @@ PATCH Grants - Method not implemented ... Test title: PATCH Grants - Method not implemented ... Test objective: The objective is to test that PATCH method is not allowed for Life cycle operation granting ... Pre-conditions: none - ... Reference: Clause 9.4.2.3.4 - ETSI GS NFV-SOL 003 [1] v3.5.1 + ... Reference: Clause 9.4.2.3.4 - ETSI GS NFV-SOL 003 [1] v3.6.1 ... Config ID: Config_prod_NFVO ... Applicability: none ... Post-Conditions: none @@ -100,7 +100,7 @@ DELETE Grants - Method not implemented ... Test title: DELETE Grants - Method not implemented ... Test objective: The objective is to test that DELETE method is not allowed for Life cycle operation granting ... Pre-conditions: none - ... Reference: Clause 9.4.2.3.5 - ETSI GS NFV-SOL 003 [1] v3.5.1 + ... Reference: Clause 9.4.2.3.5 - ETSI GS NFV-SOL 003 [1] v3.6.1 ... Config ID: Config_prod_NFVO ... Applicability: none ... Post-Conditions: resources are not deleted diff --git a/SOL003/VNFLifecycleOperationGranting-API/IndividualGrant.robot b/SOL003/VNFLifecycleOperationGranting-API/IndividualGrant.robot index 6f3309d4b..b3f12afa7 100644 --- a/SOL003/VNFLifecycleOperationGranting-API/IndividualGrant.robot +++ b/SOL003/VNFLifecycleOperationGranting-API/IndividualGrant.robot @@ -18,7 +18,7 @@ POST Individual Grant - Method not implemented ... Test title: POST Individual Grant - Method not implemented ... Test objective: The objective is to test that POST method is not allowed for Life cycle operation granting ... Pre-conditions: none - ... Reference: Clause 9.4.2.3.4 - ETSI GS NFV-SOL 003 [1] v3.5.1 + ... Reference: Clause 9.4.2.3.4 - ETSI GS NFV-SOL 003 [1] v3.6.1 ... Config ID: Config_prod_NFVO ... Applicability: none ... Post-Conditions: none @@ -30,7 +30,7 @@ GET an individual grant - Successful ... Test title: GET an individual grant - Successful ... Test objective: The objective is to retrieve a grant for a particular VNF Lifecycle Operation. ... Pre-conditions: The grant information is available to the NFVO - ... Reference: Clause 9.4.3.3.2 - ETSI GS NFV-SOL 003 [1] v3.5.1 + ... Reference: Clause 9.4.3.3.2 - ETSI GS NFV-SOL 003 [1] v3.6.1 ... Config ID: Config_prod_NFVO ... Applicability: none ... Post-Conditions: none @@ -45,7 +45,7 @@ GET an individual grant - Process ongoing ... Test title: GET an individual grant - Process ongoing ... Test objective: The objective is to retrieve a grant for a particular VNF lifecycle operation when process is ongoing and no grant is available yet. ... Pre-conditions: The process of creating the grant is ongoing, no grant is available yet. - ... Reference: Clause 9.4.3.3.2 - ETSI GS NFV-SOL 003 [1] v3.5.1 + ... Reference: Clause 9.4.3.3.2 - ETSI GS NFV-SOL 003 [1] v3.6.1 ... Config ID: Config_prod_NFVO ... Applicability: none ... Post-Conditions: none @@ -59,7 +59,7 @@ GET an individual grant - grant rejected ... Test title: GET an individual grant - grant rejected ... Test objective: The objective is to retrieve a grant for a particular VNF Lifecycle Operation but error returned because grant has been rejected. ... Pre-conditions: none - ... Reference: Clause 9.4.3.3.2 - ETSI GS NFV-SOL 003 [1] v3.5.1 + ... Reference: Clause 9.4.3.3.2 - ETSI GS NFV-SOL 003 [1] v3.6.1 ... Config ID: Config_prod_NFVO ... Applicability: none ... Post-Conditions: none @@ -72,7 +72,7 @@ PUT an individual grant - Method not implemented ... Test title: PUT an individual grant - Method not implemented ... Test objective: The objective is to test that PUT method is not allowed to for Life cycle operation granting ... Pre-conditions: none - ... Reference: Clause 9.4.3.3.3 - ETSI GS NFV-SOL 003 [1] v3.5.1 + ... Reference: Clause 9.4.3.3.3 - ETSI GS NFV-SOL 003 [1] v3.6.1 ... Config ID: Config_prod_NFVO ... Applicability: none ... Post-Conditions: none @@ -84,7 +84,7 @@ PATCH an individual grant - Method not implemented ... Test title: PATCH an individual grant - Method not implemented ... Test objective: The objective is to test that PATCH method is not allowed to for Life cycle operation granting ... Pre-conditions: none - ... Reference: Clause 9.4.3.3.4 - ETSI GS NFV-SOL 003 [1] v3.5.1 + ... Reference: Clause 9.4.3.3.4 - ETSI GS NFV-SOL 003 [1] v3.6.1 ... Config ID: Config_prod_NFVO ... Applicability: none ... Post-Conditions: none @@ -96,7 +96,7 @@ DELETE an individual grant - Method not implemented ... Test title: DELETE an individual grant - Method not implemented ... Test objective: The objective is to test that DELETE method is not allowed to for Life cycle operation granting ... Pre-conditions: none - ... Reference: Clause 9.4.3.3.5 - ETSI GS NFV-SOL 003 [1] v3.5.1 + ... Reference: Clause 9.4.3.3.5 - ETSI GS NFV-SOL 003 [1] v3.6.1 ... Config ID: Config_prod_NFVO ... Applicability: none ... Post-Conditions: none diff --git a/SOL003/VNFLifecycleOperationGranting-API/schemas/grant.schema.json b/SOL003/VNFLifecycleOperationGranting-API/schemas/grant.schema.json index 47983d9d3..89f70ebfd 100644 --- a/SOL003/VNFLifecycleOperationGranting-API/schemas/grant.schema.json +++ b/SOL003/VNFLifecycleOperationGranting-API/schemas/grant.schema.json @@ -1,5 +1,5 @@ { - "description": "This type represents a grant.\nNOTE 1: This interface allows to signal the use of multiple VIMs per VNF. However, due to the partial support of this feature in the present \n release, it is recommended in the present document that the number \n of entries in the \"vims\" attribute in the Grant is not greater than 1.\nNOTE 2: Void. NOTE 3: 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 \n in the corresponding Grant request. The NFVO may send in each Grant \n response the full set of VIM assets related to the VNF package defined \n by the vnfdId in the related Grant request, but shall send this information \n if the vnfdId in the related Grant request differs from the vnfdId passed \n in the previous Grant request, or if the Grant response is related to an \n InstantiateVnf operation. The set of VIM assets shall not change between \n subsequent Grant responses if the vnfdId has not changed. During each LCM \n operation occurrence, the VIM assets that relate to the VNF package identified \n by the current value of the vnfdId attribute in the \"VnfInstance\" structure \n shall be used by the VNFM for newly created resources. If the VNF package \n identifier of the VNF instance has been updated, VIM assets that relate to \n the previously-used VNF package(s), and that were communicated in previous \n Grant responses, apply to existing resources.\nNOTE 4: 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 \n these networks have certain properties such as security or acceleration features, \n or to address particular network topologies. The present document assumes that \n externally-managed internal VLs are managed by the NFVO and created towards the VIM.\nNOTE 5: For any VNF lifecycle management operation request that allows to pass \"extVirtualLinks\" and/or \"extManagedVirtualLinks\" parameters, such as InstantiateVnf, ChangeVnfFlavour, \n ChangeExtVnfConnectivity or ChangeCurrentVnfPackage, the NFVO may provide the \"extVirtualLinks\" \n and/or \"extManagedVirtualLinks\" attributes in the Grant to override the values passed \n in these parameters previously in the associated VNF lifecycle management request, if \n the lifecycle management request has originated from the NFVO itself. The NFVO shall \n not provide the \"extVirtualLinks\" and/or \"extManagedVirtualLinks\" attributes in the \n Grant otherwise.\nNOTE 6: The NFVO shall set the value of the attribute by copying the value from the associated GrantRequest.\nNOTE 7: 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. \n Further in case of granting an InstantiateVnf request that has originated from the NFVO \n and that did not contain the \"extManagedVirtualLinks\" attribute, this attribute shall be \n set by the NFVO if there is the need to provide information about externally-managed virtual \n links.\n", + "description": "This type represents a grant.\nNOTE 1: This interface allows to signal the use of multiple VIMs per VNF. The specification\n for managing the VNF internal VL requirements across multiple VIMs is supported via\n \"externally-managed internal VLs\" and \"multi-site connectivity services\".\nNOTE 2: Void. NOTE 3: The Grant response allows the NFVO to pass to the VNFM VIM assets related to the VNF \n package that is identified in the corresponding Grant request. Because only the operations\n InstantiateVnf, ChangeCurrentVnfPkg and the update of the vnfdId by PATCH can imply changes\n in the set of VIM assets, the NFVO shall not change this set in any other case. To signal the\n set of VIM assets, the following applies:\n a)\tIf the current LCM operation is InstantiateVnf, the NFVO shall send in the Grant response\n the full set of VIM assets related to the VNF package defined by the vnfdId in the related\n Grant request.\n b)\tIf the current LCM operation is ChangeCurrentVnfPkg, the NFVO shall send in the\n Grant response the full set of VIM assets related to the VNF package defined by the destVnfdId\n in the related Grant request.\n c)\tFor any other operation: If the set of VIM assets has changed since the end of the previous\n granted operation because a PATCH operation has changed the vnfdId between the previous granted\n operation and the operation to which the current granting exchange relates, the NFVO shall send\n in the Grant response the full set of VIM assets related to the VNF package defined by the vnfdId\n in the related Grant request. Otherwise, the NFVO shall either send in the Grant response the full\n set of VIM assets related to the VNF package defined by the vnfdId in the related Grant request, or\n shall not send any VIM assets at all.\n During each LCM operation occurrence other than a \"ChangeCurrentVnfPkg\" operation,\n the VIM assets that relate to the VNF package identified by the current value of\n the vnfdId attribute in the \"VnfInstance\" structure shall be used by the\n VNFM for newly created resources and updated resources.\nNOTE 4: The indication of externally-managed internal VLs is needed in case networks have been\n pre-configured for use with certain VNFs, for instance to ensure that these networks have\n certain properties such as security or acceleration features, or to address particular network\n topologies (e.g., multi-site connectivity). The present document assumes that externally-managed\n internal VLs are managed by the NFVO and created towards the VIM and WIM.\nNOTE 5: For any VNF lifecycle management operation request that allows to pass \"extVirtualLinks\" and/or\n \"extManagedVirtualLinks\" parameters, such as InstantiateVnf, ChangeVnfFlavour, ChangeExtVnfConnectivity or\n ChangeCurrentVnfPackage, the NFVO may provide the \"extVirtualLinks\" and/or \"extManagedVirtualLinks\" attributes\n in the Grant to override the values passed in these parameters previously in the associated VNF lifecycle\n management request, if the lifecycle management request has originated from the NFVO itself. The NFVO shall\n not provide the \"extVirtualLinks\" and/or \"extManagedVirtualLinks\" attributes in the Grant in case the LCM\n request did not originate from the NFVO itself or the granted LCM operation request does not allow to pass\n these parameters.\nNOTE 6: The NFVO shall set the value of the attribute by copying the value from the associated \n GrantRequest.\nNOTE 7: In case of granting an InstantiateVnf request that has originated from the NFVO and that \n did not contain the \"extVirtualLinks\" attribute, this attribute shall be set by the NFVO. \n Further in case of granting an InstantiateVnf request that has originated from the NFVO \n and that did not contain the \"extManagedVirtualLinks\" attribute, this attribute shall be \n set by the NFVO if there is the need to provide information about externally-managed virtual \n links.\nNOTE 8: The resulting \"extVirtualLinks\" or \"extManagedVirtualLinks\" information is calculated as follows: \n In a first step, the information passed in the related LCM operation is applied to the baseline\n information known from earlier LCM operation executions. In a second step, the information passed\n in the Grant is applied to the information resulting from the first step.\n", "type": "object", "required": ["id", "vnfInstanceId", "vnfLcmOpOccId", "_links"], "properties": { @@ -16,7 +16,7 @@ "type": "string" }, "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.\nThe VNFM shall update the \"vimConnectionInfo\" attribute of the \"VnfInstance\" structure by adding unknown entries received in this attribute.\nThis attribute is not intended for the modification of VimConnectionInfo entries passed earlier; for that, the VnfInfoModificationRequest structure shall be used.\nThis 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.\n", + "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. \nThe VNFM shall update the \"vimConnectionInfo\" attribute of the \"VnfInstance\" structure by adding unknown entries received in this attribute. \nThis attribute is not intended for the modification of VimConnectionInfo entries passed earlier; for that, the VnfInfoModificationRequest structure shall be used.\nThis 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.\n", "type": "object", "additionalProperties": { "description": "This type represents parameters to connect to a VIM for managing the resources of a VNF instance. * NOTE 1:\tIf applicable, this attribute also provides information about the resourceGroupIds\n that are accessible using a particular set of credentials. See definition of\n \"resourceGroupId\" in clause 9.5.3.3.\n* NOTE 2:\tOnce the connectivity between VNFM and VIM is provided through a secure connection over\n HTTP Secure (HTTP over SSL/TLS), and the connection might also be established through a VPN\n (for example TLS-based VPN tunnelling) for site-to-site connection, the \"accessInfo\" JSON data\n structure, and the sensitive data related information (\"username\"/\"password\" as required properties\n for authentication purpose), will be transmitted as plain text through a TLS tunnel without additional\n encoding/encryption before transmitting it, making the sensitive data visible to the endpoint.\n The base64 encoded certificates are only used by the VNFM to verify the authenticity of the\n interface endpoint of the VIM.\n", @@ -296,7 +296,11 @@ "items": { "description": "This type contains a mapping between a snapshot resource definition related to a VNF snapshot and the corresponding resource managed by the NFVO in the VIM which is needed during the revert to VNF snapshot operation.\n", "type": "object", - "required": ["vnfSnapshotId", "vnfcSnapshotId", "vimSnapshotResourceId"], + "required": [ + "vnfSnapshotId", + "vnfcSnapshotId", + "vimSnapshotResourceId" + ], "properties": { "vimConnectionId": { "description": "An identifier with the intention of being globally unique.\n", @@ -315,7 +319,8 @@ "type": "string" }, "storageSnapshotId": { - "description": "Identifier of the virtual storage resource that has been snapshotted as referred in the VNFC snapshot information. Shall only be present if the snapshot resource in the VIM is a storage resource (as indicated by \"type=STORAGE\" in the parent resource definition). $ref: \"../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnf\"\n" + "description": "An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n", + "type": "string" }, "vimSnapshotResourceId": { "description": "An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.\n", @@ -327,7 +332,7 @@ } }, "extVirtualLinks": { - "description": "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.\n", + "description": "Information about external VLs to connect the VNF to. See notes 5, 7 and 8. 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.\n", "type": "array", "items": { "description": "This type represents an external VL. * NOTE:\tA link port is not needed for an external CP instance that exposes a VIP CP in the following cases:\n 1\tFor a VIP CP directly exposed as extCP:\n 1.1\tNo dedicated IP address is allocated as VIP address, as indicated in the VNFD.\n 1.2\tA dedicated IP addresss is allocated as VIP address, but the NFVO indicates that no port\n is needed (createExtLinkPort in VnfExtCpconfig set to false).\n 2\tFor a VIP CP exposed as extCP via a floating IP address:\n 2.1\tNo dedicated IP address is allocated as VIP address, as indicated in the VNFD, and the VNFC\n CP associated to the VIP CP is also exposed via a floating IP addresss.\n", @@ -354,7 +359,7 @@ "description": "External CPs of the VNF to be connected to this external VL. Entries in the list of external CP data that are unchanged need not be supplied if the ExtVirtualLinkData structure is part of a request or response that modifies the external connectivity.\n", "type": "array", "items": { - "description": "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n", + "description": "This type represents configuration information for external CPs created. * NOTE 1: \tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created\n from this CPD will represent ports in a trunk.\n* NOTE 2: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external\n connectivity. Thus, given a particular value of the \"cpdId\" attribute, there shall be one\n \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes\n a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk,\n all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are\n connected to the same set of external VLs via the trunk.\n* NOTE 3: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified\n by a particular key value from the map, i.e. for the disconnection of an existing external\n CP instance addressed by cpInstanceId in the deleted map entry from a particular external\n virtual link, and deletion of that instance in case it represents a subport. Deleting the\n last key from the map removes the affected instance of the \"VnfExtCpData\" structure from\n its parent data structure.\n* NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or \n \"ChangeCurrentVnfPkg\" operation or as part of the Grant response for any of these operations, a \n cpConfig map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\"\n or \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance\n different than the one that has used it before the operation, or by no external CP instance at all.\n Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the\n related \"cpConfig\" map entries to a new \"extCpData\" structure.\n", "type": "object", "required": ["cpdId"], "properties": { @@ -363,15 +368,18 @@ "type": "string" }, "cpConfig": { - "description": "Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is managed by the API consumer. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See note 2 and note 3.\n", + "description": "Map of instance data that need to be configured on the CP instances created from the respective CPD. The key of the map which identifies the individual VnfExtCpConfig entries is of type \"IdentifierInVnf\" and is managed by the API consumer. The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396). See notes 2, 3 and 4.\n", "type": "object", "additionalProperties": { - "description": "This type represents an externally provided link port or network address information per instance of an external connection point. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the external VL. In a link port is not provided, the VNFM shall create a link port on the external VL, and use that link port to connect the external CP to the external VL. * NOTE: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\": 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external\n CP instance representing a subport that is to be created, or an external CP instance that is to be\n created by creating the corresponding VNFC or VNF instance during the current or a subsequent LCM\n operation, or for an existing external CP instance that is to be re-configured or added to a\n particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing\n a pre created link port, and the VNFM can use means outside the scope of the present document to obtain\n the pre-configured address information for the connection point from the resource representing\n the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the API consumer shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n", - "anyOf": [{ - "required": ["linkPortId"] - }, { - "required": ["cpProtocolData"] - }], + "description": "This type represents an externally provided link port or network address information per instance of an external connection point. In case a link port is provided, the VNFM shall use that link port when connecting the external CP to the external VL. In a link port is not provided, the VNFM shall create a link port on the external VL, and use that link port to connect the external CP to the external VL. * NOTE: The following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\":\n 1) Void.\n 2) At least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for an external\n CP instance representing a subport that is to be created, or an external CP instance that is to be\n created by creating the corresponding VNFC or VNF instance during the current or a subsequent LCM\n operation, or for an existing external CP instance that is to be re-configured or added to a\n particular external virtual link.\n 3) If the \"linkPortId\" attribute is absent, the VNFM shall create a link port.\n 4) If the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided referencing\n a pre created link port, and the VNFM can use means outside the scope of the present document to obtain\n the pre-configured address information for the connection point from the resource representing\n the link port.\n 5) If both \"cpProtocolData\" and \"linkportId\" are provided, the API consumer shall ensure that the\n cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\n", + "anyOf": [ + { + "required": ["linkPortId"] + }, + { + "required": ["cpProtocolData"] + } + ], "type": "object", "properties": { "parentCpConfigId": { @@ -400,20 +408,27 @@ "enum": ["IP_OVER_ETHERNET"] }, "ipOverEthernet": { - "description": "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVI’s transport technology.\n", + "description": "This type represents network address data for IP over Ethernet. * NOTE 1:\tAt least one of \"macAddress\" or \"ipAddresses\" shall be present. * NOTE 2:\tExactly one of \"fixedAddresses\", \"numDynamicAddresses\" or \"ipAddressRange\" shall be present. * NOTE 3:\tIf the CP instance represents a subport in a trunk, segmentationId shall be present.\n Otherwise it shall not be present.\n* NOTE 4:\tDepending on the NFVI networking infrastructure, the segmentationId may indicate the actual\n network segment value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header\n of the packets or it may be an identifier used between the application and the NFVI networking\n infrastructure to identify the network sub-interface of the trunk port in question. In the latter\n case the NFVI infrastructure will map this local segmentationId to whatever segmentationId is\n actually used by the NFVIΓÇÖs transport technology.\n", "type": "object", - "anyOf": [{ - "required": ["macAddress"] - }, { - "required": ["ipAddresses"] - }], - "oneOf": [{ - "required": ["fixedAddresses"] - }, { - "required": ["numDynamicAddresses"] - }, { - "required": ["ipAddressRange"] - }], + "anyOf": [ + { + "required": ["macAddress"] + }, + { + "required": ["ipAddresses"] + } + ], + "oneOf": [ + { + "required": ["fixedAddresses"] + }, + { + "required": ["numDynamicAddresses"] + }, + { + "required": ["ipAddressRange"] + } + ], "properties": { "macAddress": { "description": "A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.\n", @@ -421,7 +436,7 @@ "format": "MAC" }, "segmentationType": { - "description": "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network it’s connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n", + "description": "Specifies the encapsulation type for the traffics coming in and out of the trunk subport. Permitted values: -\tVLAN: the subport uses VLAN as encapsulation type. -\tINHERIT: the subport gets its segmentation type from the network itΓÇÖs connected to. This attribute may be present for CP instances that represent subports in a trunk and shall be absent otherwise. If this attribute is not present for a subport CP instance, default value VLAN shall be used.\n", "type": "string", "enum": ["VLAN", "INHERIT"] }, @@ -457,7 +472,10 @@ "addressRange": { "description": "An IP address range to be used, e.g. in case of egress connections. In case this attribute is present, IP addresses from the range will be used. See note 2.\n", "type": "object", - "required": ["minAddress", "maxAddress"], + "required": [ + "minAddress", + "maxAddress" + ], "properties": { "minAddress": { "description": "An IPV4 or IPV6 address. Representation: In case of an IPV4 address, string that consists of four decimal integers separated by dots, each integer ranging from 0 to 255. In case of an IPV6 address, string that consists of groups of zero to four hexadecimal digits, separated by colons.\n", @@ -535,7 +553,7 @@ } }, "extManagedVirtualLinks": { - "description": "Information about internal VLs that are managed by other entities than the VNFM. See notes 4, 5 and 7.\n", + "description": "Information about internal VLs that are managed by other entities than the VNFM. See notes 4, 5, 7 and 8.\n", "type": "array", "items": { "type": "object", -- GitLab From 3d74ecff5da2aa39ec3a93d62cceabc1cf39c74a Mon Sep 17 00:00:00 2001 From: muhammadh Date: Mon, 27 Jun 2022 14:54:33 +0500 Subject: [PATCH 2/2] fix identation in descriptors file for SOL003 VNF Lifecycle Ope Gran API --- .../descriptors/SOL006/VNFD/vnfd_SOL006.yaml | 28 +++++++++---------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/SOL003/VNFLifecycleOperationGranting-API/descriptors/SOL006/VNFD/vnfd_SOL006.yaml b/SOL003/VNFLifecycleOperationGranting-API/descriptors/SOL006/VNFD/vnfd_SOL006.yaml index d902779a2..26da50f3a 100644 --- a/SOL003/VNFLifecycleOperationGranting-API/descriptors/SOL006/VNFD/vnfd_SOL006.yaml +++ b/SOL003/VNFLifecycleOperationGranting-API/descriptors/SOL006/VNFD/vnfd_SOL006.yaml @@ -10,26 +10,26 @@ nfv: - id: vdu-b-1 name: VNF-B VDU 1 int-cpd: - - id: left - layer-protocol: ethernet - - id: management - layer-protocol: ethernet - - id: internal - layer-protocol: ethernet - int-virtual-link-desc: internal-vl + - id: left + layer-protocol: ethernet + - id: management + layer-protocol: ethernet + - id: internal + layer-protocol: ethernet + int-virtual-link-desc: internal-vl virtual-compute-desc: vdu-b-1-vcd virtual-storage-desc: vdu-b-1-vsd sw-image-desc: vdu-b-1-image - id: vdu-b-2 name: VNF-B VDU 2 int-cpd: - - id: right - layer-protocol: ethernet - - id: management - layer-protocol: ethernet - - id: internal - layer-protocol: ethernet - int-virtual-link-desc: internal-vl + - id: right + layer-protocol: ethernet + - id: management + layer-protocol: ethernet + - id: internal + layer-protocol: ethernet + int-virtual-link-desc: internal-vl virtual-compute-desc: vdu-b-2-vcd virtual-storage-desc: vdu-b-2-vsd sw-image-desc: vdu-b-2-image -- GitLab