"description":"Name to identify the VNF Product. The value is copied from the VNFD.\n",
"description":"Name to identify the VNF Product. The value is copied from the VNFD.\n",
"type":"string"
},
"vnfSoftwareVersion":{
...
...
@@ -350,6 +350,10 @@
"description":"Identifier of the VNF Virtual Link Descriptor (VLD) in the VNFD.\n",
"type":"string"
},
"vnfdId":{
"description":"An identifier with the intention of being globally unique.\n",
"type":"string"
},
"vnfExtCpId":{
"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
"type":"string"
...
...
@@ -597,7 +601,7 @@
}
},
"currentVnfExtCpData":{
"description":"This type represents configuration information for external CPs created from a CPD.\nNOTE 1:\tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created from this CPD will represent ports in a trunk. NOTE 2: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified by a particular key value from the map, i.e. for the disconnection of an existing external CP instance addressed by cpInstanceId in the deleted map entry from a particular external virtual link, and deletion of that instance in case it represents a subport. Deleting the last key from the map removes the affected instance of the \"VnfExtCpData\" structure from its parent data structure. NOTE 3: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external connectivity. Thus, given a particular value of the \"cpdId' attribute, there shall be one \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk, all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are connected to the same set of external VLs via the trunk.\n",
"description":"This type represents configuration information for external CPs created from a CPD.\nNOTE 1:\tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created from this CPD will represent ports in a trunk. NOTE 2: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified by a particular key value from the map, i.e. for the disconnection of an existing external CP instance addressed by cpInstanceId in the deleted map entry from a particular external virtual link, and deletion of that instance in case it represents a subport. Deleting the last key from the map removes the affected instance of the \"VnfExtCpData\" structure from its parent data structure. NOTE 3: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external connectivity. Thus, given a particular value of the \"cpdId' attribute, there shall be one \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk, all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are connected to the same set of external VLs via the trunk. NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance different than the one that has used it before the operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n",
"type":"object",
"required":["cpdId"],
"properties":{
...
...
@@ -606,7 +610,7 @@
"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 [11]). 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 1:\tThe following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\":\n -\tAt least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for\n an external CP instance representing a subport that is to be created, or an external CP instance\n that is to be created by creating the corresponding VNFC or VNF instance during the current or\n a subsequent LCM operation, or for an existing external CP instance that is to be re-configured\n or added to a particular external virtual link.\n -\tIf the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided\n referencing a pre-created link port with pre-configured address information.\n -\tIf both \"cpProtocolData\" and \"linkportId\" are provided, the API consumer shall ensure that\n the cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\nNOTE 2:\tIn case the NFVO manages its own identifier space, the NFVO may remap this identifier when communicating with the VNFM. If the NFVO knows that there can be an identifier collision when communicating with the VNFM by using the identifier from the OSS/BSS, the NFVO shall remap it.\n",
"description":"This type represents a response for Query NS operation. It shall comply with the provisions defined in Table 6.5.2.10-1.\nNOTE 1:\tIf the \"nsState\" attribute is INSTANTIATED, at least either one\n\"vnfInstance\" attribute or one \"nestedNsInstanceId\" attribute shall be present.\nNOTE 2:\tThe “priority” attribute of the NS instance is configured in the NSD in the NsDf structure.\n The mapping from application-specific priority values to a value in the NsDf is under OSS/BSS responsibility.\n The \"zero\" value expresses the highest priority and the fact that the NS instance based on this DF cannot be\n pre-empted during resource allocation.\nNOTE 3:\tExamples for the usage of priority include conflict resolution in case of resource shortage\n",
"description":"Identifier of the VNF Virtual Link Descriptor (VLD) in the VNFD.\n",
"type":"string"
},
"vnfdId":{
"description":"An identifier with the intention of being globally unique.\n",
"type":"string"
},
"vnfExtCpId":{
"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
"type":"string"
...
...
@@ -600,7 +603,7 @@
}
},
"currentVnfExtCpData":{
"description":"This type represents configuration information for external CPs created from a CPD.\nNOTE 1:\tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created from this CPD will represent ports in a trunk. NOTE 2: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified by a particular key value from the map, i.e. for the disconnection of an existing external CP instance addressed by cpInstanceId in the deleted map entry from a particular external virtual link, and deletion of that instance in case it represents a subport. Deleting the last key from the map removes the affected instance of the \"VnfExtCpData\" structure from its parent data structure. NOTE 3: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external connectivity. Thus, given a particular value of the \"cpdId' attribute, there shall be one \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk, all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are connected to the same set of external VLs via the trunk.\n",
"description":"This type represents configuration information for external CPs created from a CPD.\nNOTE 1:\tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created from this CPD will represent ports in a trunk. NOTE 2: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified by a particular key value from the map, i.e. for the disconnection of an existing external CP instance addressed by cpInstanceId in the deleted map entry from a particular external virtual link, and deletion of that instance in case it represents a subport. Deleting the last key from the map removes the affected instance of the \"VnfExtCpData\" structure from its parent data structure. NOTE 3: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external connectivity. Thus, given a particular value of the \"cpdId' attribute, there shall be one \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk, all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are connected to the same set of external VLs via the trunk. NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance different than the one that has used it before the operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n",
"type":"object",
"required":["cpdId"],
"properties":{
...
...
@@ -609,7 +612,7 @@
"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 [11]). 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 1:\tThe following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\":\n -\tAt least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for\n an external CP instance representing a subport that is to be created, or an external CP instance\n that is to be created by creating the corresponding VNFC or VNF instance during the current or\n a subsequent LCM operation, or for an existing external CP instance that is to be re-configured\n or added to a particular external virtual link.\n -\tIf the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided\n referencing a pre-created link port with pre-configured address information.\n -\tIf both \"cpProtocolData\" and \"linkportId\" are provided, the API consumer shall ensure that\n the cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\nNOTE 2:\tIn case the NFVO manages its own identifier space, the NFVO may remap this identifier when communicating with the VNFM. If the NFVO knows that there can be an identifier collision when communicating with the VNFM by using the identifier from the OSS/BSS, the NFVO shall remap it.\n",
...
...
@@ -2466,7 +2469,7 @@
"required":["href"],
"properties":{
"href":{
"description":"URI of a resource referenced from a notification. Should be an absolute URI (i.e. a URI that contains {apiRoot}), however, may be a relative URI (i.e. a URI where the {apiRoot} part is omitted) if the {apiRoot} information is not available.\n",
"description":"URI of a resource referenced from a notification. Should be an absolute URI (i.e. a URI that contains {apiRoot}), however, may be a relative URI (i.e. a URI where the {apiRoot} part is omitted) if the {apiRoot} information is not available.\n",
"description":"Identifier of the VNF Virtual Link Descriptor (VLD) in the VNFD.\n",
"type":"string"
},
"vnfdId":{
"description":"An identifier with the intention of being globally unique.\n",
"type":"string"
},
"vnfExtCpId":{
"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
"type":"string"
...
...
@@ -599,7 +603,7 @@
}
},
"currentVnfExtCpData":{
"description":"This type represents configuration information for external CPs created from a CPD.\nNOTE 1:\tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created from this CPD will represent ports in a trunk. NOTE 2: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified by a particular key value from the map, i.e. for the disconnection of an existing external CP instance addressed by cpInstanceId in the deleted map entry from a particular external virtual link, and deletion of that instance in case it represents a subport. Deleting the last key from the map removes the affected instance of the \"VnfExtCpData\" structure from its parent data structure. NOTE 3: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external connectivity. Thus, given a particular value of the \"cpdId' attribute, there shall be one \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk, all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are connected to the same set of external VLs via the trunk.\n",
"description":"This type represents configuration information for external CPs created from a CPD.\nNOTE 1:\tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created from this CPD will represent ports in a trunk. NOTE 2: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified by a particular key value from the map, i.e. for the disconnection of an existing external CP instance addressed by cpInstanceId in the deleted map entry from a particular external virtual link, and deletion of that instance in case it represents a subport. Deleting the last key from the map removes the affected instance of the \"VnfExtCpData\" structure from its parent data structure. NOTE 3: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external connectivity. Thus, given a particular value of the \"cpdId' attribute, there shall be one \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk, all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are connected to the same set of external VLs via the trunk. NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance different than the one that has used it before the operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n",
"type":"object",
"required":["cpdId"],
"properties":{
...
...
@@ -608,7 +612,7 @@
"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 [11]). 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 1:\tThe following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\":\n -\tAt least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for\n an external CP instance representing a subport that is to be created, or an external CP instance\n that is to be created by creating the corresponding VNFC or VNF instance during the current or\n a subsequent LCM operation, or for an existing external CP instance that is to be re-configured\n or added to a particular external virtual link.\n -\tIf the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided\n referencing a pre-created link port with pre-configured address information.\n -\tIf both \"cpProtocolData\" and \"linkportId\" are provided, the API consumer shall ensure that\n the cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\nNOTE 2:\tIn case the NFVO manages its own identifier space, the NFVO may remap this identifier when communicating with the VNFM. If the NFVO knows that there can be an identifier collision when communicating with the VNFM by using the identifier from the OSS/BSS, the NFVO shall remap it.\n",
"description":"Identifier of the VNF Virtual Link Descriptor (VLD) in the VNFD.\n",
"type":"string"
},
"vnfdId":{
"description":"An identifier with the intention of being globally unique.\n",
"type":"string"
},
"vnfExtCpId":{
"description":"An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.\n",
"type":"string"
...
...
@@ -601,7 +605,7 @@
}
},
"currentVnfExtCpData":{
"description":"This type represents configuration information for external CPs created from a CPD.\nNOTE 1:\tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created from this CPD will represent ports in a trunk. NOTE 2: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified by a particular key value from the map, i.e. for the disconnection of an existing external CP instance addressed by cpInstanceId in the deleted map entry from a particular external virtual link, and deletion of that instance in case it represents a subport. Deleting the last key from the map removes the affected instance of the \"VnfExtCpData\" structure from its parent data structure. NOTE 3: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external connectivity. Thus, given a particular value of the \"cpdId' attribute, there shall be one \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk, all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are connected to the same set of external VLs via the trunk.\n",
"description":"This type represents configuration information for external CPs created from a CPD.\nNOTE 1:\tIn case this identifier refers to a CPD with trunking enabled, the external CP instances created from this CPD will represent ports in a trunk. NOTE 2: \tThe map entry value shall be set to \"null\" in order to delete a \"VnfExtCpConfig\" entry identified by a particular key value from the map, i.e. for the disconnection of an existing external CP instance addressed by cpInstanceId in the deleted map entry from a particular external virtual link, and deletion of that instance in case it represents a subport. Deleting the last key from the map removes the affected instance of the \"VnfExtCpData\" structure from its parent data structure. NOTE 3: \tWithin one VNF instance, all VNFC instances created from a particular VDU have the same external connectivity. Thus, given a particular value of the \"cpdId' attribute, there shall be one \"cpConfig\" entry for each VNFC instance that has been or can be created from a VDU which includes a CPD identified by the \"cpdId\" attribute. If the cpConfig represents a subport in a trunk, all \"cpConfig\" entries in this list shall have the same segmentationId, which means they are connected to the same set of external VLs via the trunk. NOTE 4: If, as defined by the input parameters of a \"ChangeVnfFlavour\", \"ChangeExtVnfConnectivity\" or \"ChangeCurrentVnfPkg\" operation, a cpConfig map entry identified by a particular map key value is moved into another \"ExtVirtualLinkData\" or \"VnfExtCpData\" structure, this particular cpConfig map entry may be used by an external CP instance different than the one that has used it before the operation, or by no external CP instance at all. Renaming a CPD identifier during the \"changeCurrentVnfPkg\" operation does not count as moving the related \"cpConfig\" map entries to a new \"extCpData\" structure.\n",
"type":"object",
"required":["cpdId"],
"properties":{
...
...
@@ -610,7 +614,7 @@
"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 [11]). 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 1:\tThe following conditions apply to the attributes \"linkPortId\" and \"cpProtocolData\":\n -\tAt least one of the \"linkPortId\" and \"cpProtocolData\" attributes shall be present for\n an external CP instance representing a subport that is to be created, or an external CP instance\n that is to be created by creating the corresponding VNFC or VNF instance during the current or\n a subsequent LCM operation, or for an existing external CP instance that is to be re-configured\n or added to a particular external virtual link.\n -\tIf the \"cpProtocolData\" attribute is absent, the \"linkPortId\" attribute shall be provided\n referencing a pre-created link port with pre-configured address information.\n -\tIf both \"cpProtocolData\" and \"linkportId\" are provided, the API consumer shall ensure that\n the cpProtocolData can be used with the pre-created link port referenced by \"linkPortId\".\nNOTE 2:\tIn case the NFVO manages its own identifier space, the NFVO may remap this identifier when communicating with the VNFM. If the NFVO knows that there can be an identifier collision when communicating with the VNFM by using the identifier from the OSS/BSS, the NFVO shall remap it.\n",