Loading src/SOL003/VNFLifecycleManagement/VNFLifecycleManagement.yaml +1 −1 Original line number Diff line number Diff line Loading @@ -2096,7 +2096,7 @@ paths: Shall be returned when the state of the VNF lifecycle management operation occurrence has been changed successfully. The response shall include a representation of the "Individual VNF lifecycle operation occurrence" resource. The response body shall include a representation of the "Individual VNF lifecycle operation occurrence" resource. headers: Content-Type: description: The MIME type of the body of the response. Loading src/SOL003/VNFLifecycleManagement/definitions/SOL003VNFLifecycleManagement_def.yaml +7 −3 Original line number Diff line number Diff line Loading @@ -216,7 +216,7 @@ definitions: 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 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. These 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 Loading Loading @@ -832,7 +832,7 @@ definitions: $ref: "../../../definitions/SOL002SOL003VNFLifecycleManagement_def.yaml#/definitions/CpProtocolInfo" vnfLinkPortId: description: > Identifier of the "VnfLinkPorts" structure in the Identifier of the "VnfLinkPortInfo" structure in the "VnfVirtualLinkResourceInfo" structure. Shall be present if the CP is associated to a link port on an internal VL of the VNF instance and shall be absent otherwise. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" Loading Loading @@ -1109,7 +1109,7 @@ definitions: link instance, not the link port instance. The resource handles of the affected VNF link ports can be found by dereferencing the identifiers in the "vnfLinkPortIds" attribute. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/ResourceHandle" virtualLinkPortIds: vnfLinkPortIds: description: > Identifiers of the link ports of the affected VL related to the change. Each identifier references a "VnfLinkPortInfo" structure. Loading Loading @@ -1142,6 +1142,10 @@ definitions: ports, the "networkResource" and "resourceDefinitionId" attributes refer to the affected virtual link instance, not the link port instance. The resource handles of the affected VNF link ports can be found by dereferencing the identifiers in the "vnfLinkPortIds" attribute. NOTE 2: 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". $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierLocal" zoneId: description: > Loading src/SOL003/VNFLifecycleManagementNotification/VNFLifecycleManagementNotification.yaml +2 −2 Original line number Diff line number Diff line Loading @@ -238,7 +238,7 @@ paths: get: description: > The GET method allows the server to test the notification endpoint that is provided by the API consumer, The GET method allows the API producer to test the notification endpoint that is provided by the API consumer, e.g. during subscription. This method shall follow the provisions specified in the tables 5.4.20.3.2-1 and 5.4.20.3.2-2 for URI query parameters, request and response data structures, and response codes. Loading Loading @@ -370,7 +370,7 @@ paths: get: description: > The GET method allows the server to test the notification endpoint that is provided by the API consumer, The GET method allows the API producer to test the notification endpoint that is provided by the API consumer, e.g. during subscription. This method shall follow the provisions specified in the tables 5.4.20.3.2-1 and 5.4.20.3.2-2 for URI query parameters, request and response data structures, and response codes. Loading src/SOL003/VNFLifecycleOperationGranting/definitions/VNFLifecycleOperationGranting_def.yaml +1 −1 Original line number Diff line number Diff line Loading @@ -445,7 +445,7 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnfd" resourceTemplateId: description: > Reference to athe applicable resource template in the VNFD as follows: Reference to the applicable resource template in the VNFD as follows: - If type="VL": VnfVirtualLinkDesc, - If type="COMPUTE": VirtualComputeDesc, - If type="LINKPORT": VnfExtCpd, Loading src/SOL003/VNFPackageManagement/VNFPackageManagement.yaml +31 −14 Original line number Diff line number Diff line Loading @@ -622,24 +622,41 @@ paths: The GET method reads the content of the VNFD within a VNF package. The VNFD is implemented as a collection of one or more files. A ZIP archive embedding these files shall be returned when reading this resource. The default format of the ZIP archive shall be the one specified in ETSI GS NFV-SOL 004 where only the files representing the VNFD and information needed to navigate the ZIP archive and to identify the file that is the entry point for parsing the VNFD, and, if requested, further security information are included. This means that the structure of the ZIP archive shall correspond to the directory structure used in the VNF package and that the archive shall contain the following files from the package: • TOSCA.meta (if available in the package) • The main TOSCA definitions YAML file (either as referenced from TOSCA.meta or available as a file with the extension ".yml" or ".yaml" from the root of the archive) • Every component of the VNFD referenced (recursively) from the main TOSCA definitions YAML file • The related security information, if the "include_signatures" URI parameter is provided, as follows: The default format of the ZIP archive shall comply with CSAR format as specified in ETSI GS NFV-SOL 004 where only the files representing the VNFD and information needed to navigate the ZIP archive and to identify the file that is the entry point for parsing the VNFD, and, if requested, further security information are included, and software images as well as other artifacts referenced from the YAML files are excluded. This means that the structure of the ZIP archive shall correspond to the directory structure used in the VNF package and that the archive shall contain the following files from the package: • TOSCA.meta (if available in the package). • The main TOSCA definitions YAML file (either as referenced from TOSCA.meta or available as a file with the extension ".yml" or ".yaml" from the root of the archive). • Every component of the VNFD referenced (recursively) from the main TOSCA definitions YAML file. NOTE 1: For a VNFD based on TOSCA, it includes all the imported type definition files as indicated in the top level service template and in any of the lower level service template if it has any as described in ETSI GS NFV-SOL 001. NOTE 2: For a VNFD based on YANG, it includes the file as indicated by the "yang_definitions" keyname in the metadata section of the main yaml file as described in ETSI GS NFV-SOL 004. • The related security information, if the "include_signatures" URI parameter is provided, as follows: - the manifest file - the singleton certificate file in the root of the VNF package (if available in the package) - the signing certificates of the individual files included in the ZIP archive (if available in the package) - the singleton certificate file in the root of the VNF package (if available in the package) - the signing certificates of the individual files included in the ZIP archive (if available in the package) - the signatures of the individual files (if available in the package) Three examples are provided below. NOTE: These examples do not show the security related files. NOTE 3: These examples do not show the security related files. EXAMPLE 1: Assuming a request is sent for the following VNF package (as described in clause A.1 in ETSI GS NFV-SOL 004): Loading Loading
src/SOL003/VNFLifecycleManagement/VNFLifecycleManagement.yaml +1 −1 Original line number Diff line number Diff line Loading @@ -2096,7 +2096,7 @@ paths: Shall be returned when the state of the VNF lifecycle management operation occurrence has been changed successfully. The response shall include a representation of the "Individual VNF lifecycle operation occurrence" resource. The response body shall include a representation of the "Individual VNF lifecycle operation occurrence" resource. headers: Content-Type: description: The MIME type of the body of the response. Loading
src/SOL003/VNFLifecycleManagement/definitions/SOL003VNFLifecycleManagement_def.yaml +7 −3 Original line number Diff line number Diff line Loading @@ -216,7 +216,7 @@ definitions: 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 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. These 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 Loading Loading @@ -832,7 +832,7 @@ definitions: $ref: "../../../definitions/SOL002SOL003VNFLifecycleManagement_def.yaml#/definitions/CpProtocolInfo" vnfLinkPortId: description: > Identifier of the "VnfLinkPorts" structure in the Identifier of the "VnfLinkPortInfo" structure in the "VnfVirtualLinkResourceInfo" structure. Shall be present if the CP is associated to a link port on an internal VL of the VNF instance and shall be absent otherwise. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnf" Loading Loading @@ -1109,7 +1109,7 @@ definitions: link instance, not the link port instance. The resource handles of the affected VNF link ports can be found by dereferencing the identifiers in the "vnfLinkPortIds" attribute. $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/ResourceHandle" virtualLinkPortIds: vnfLinkPortIds: description: > Identifiers of the link ports of the affected VL related to the change. Each identifier references a "VnfLinkPortInfo" structure. Loading Loading @@ -1142,6 +1142,10 @@ definitions: ports, the "networkResource" and "resourceDefinitionId" attributes refer to the affected virtual link instance, not the link port instance. The resource handles of the affected VNF link ports can be found by dereferencing the identifiers in the "vnfLinkPortIds" attribute. NOTE 2: 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". $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierLocal" zoneId: description: > Loading
src/SOL003/VNFLifecycleManagementNotification/VNFLifecycleManagementNotification.yaml +2 −2 Original line number Diff line number Diff line Loading @@ -238,7 +238,7 @@ paths: get: description: > The GET method allows the server to test the notification endpoint that is provided by the API consumer, The GET method allows the API producer to test the notification endpoint that is provided by the API consumer, e.g. during subscription. This method shall follow the provisions specified in the tables 5.4.20.3.2-1 and 5.4.20.3.2-2 for URI query parameters, request and response data structures, and response codes. Loading Loading @@ -370,7 +370,7 @@ paths: get: description: > The GET method allows the server to test the notification endpoint that is provided by the API consumer, The GET method allows the API producer to test the notification endpoint that is provided by the API consumer, e.g. during subscription. This method shall follow the provisions specified in the tables 5.4.20.3.2-1 and 5.4.20.3.2-2 for URI query parameters, request and response data structures, and response codes. Loading
src/SOL003/VNFLifecycleOperationGranting/definitions/VNFLifecycleOperationGranting_def.yaml +1 −1 Original line number Diff line number Diff line Loading @@ -445,7 +445,7 @@ definitions: $ref: "../../../definitions/SOL002SOL003_def.yaml#/definitions/IdentifierInVnfd" resourceTemplateId: description: > Reference to athe applicable resource template in the VNFD as follows: Reference to the applicable resource template in the VNFD as follows: - If type="VL": VnfVirtualLinkDesc, - If type="COMPUTE": VirtualComputeDesc, - If type="LINKPORT": VnfExtCpd, Loading
src/SOL003/VNFPackageManagement/VNFPackageManagement.yaml +31 −14 Original line number Diff line number Diff line Loading @@ -622,24 +622,41 @@ paths: The GET method reads the content of the VNFD within a VNF package. The VNFD is implemented as a collection of one or more files. A ZIP archive embedding these files shall be returned when reading this resource. The default format of the ZIP archive shall be the one specified in ETSI GS NFV-SOL 004 where only the files representing the VNFD and information needed to navigate the ZIP archive and to identify the file that is the entry point for parsing the VNFD, and, if requested, further security information are included. This means that the structure of the ZIP archive shall correspond to the directory structure used in the VNF package and that the archive shall contain the following files from the package: • TOSCA.meta (if available in the package) • The main TOSCA definitions YAML file (either as referenced from TOSCA.meta or available as a file with the extension ".yml" or ".yaml" from the root of the archive) • Every component of the VNFD referenced (recursively) from the main TOSCA definitions YAML file • The related security information, if the "include_signatures" URI parameter is provided, as follows: The default format of the ZIP archive shall comply with CSAR format as specified in ETSI GS NFV-SOL 004 where only the files representing the VNFD and information needed to navigate the ZIP archive and to identify the file that is the entry point for parsing the VNFD, and, if requested, further security information are included, and software images as well as other artifacts referenced from the YAML files are excluded. This means that the structure of the ZIP archive shall correspond to the directory structure used in the VNF package and that the archive shall contain the following files from the package: • TOSCA.meta (if available in the package). • The main TOSCA definitions YAML file (either as referenced from TOSCA.meta or available as a file with the extension ".yml" or ".yaml" from the root of the archive). • Every component of the VNFD referenced (recursively) from the main TOSCA definitions YAML file. NOTE 1: For a VNFD based on TOSCA, it includes all the imported type definition files as indicated in the top level service template and in any of the lower level service template if it has any as described in ETSI GS NFV-SOL 001. NOTE 2: For a VNFD based on YANG, it includes the file as indicated by the "yang_definitions" keyname in the metadata section of the main yaml file as described in ETSI GS NFV-SOL 004. • The related security information, if the "include_signatures" URI parameter is provided, as follows: - the manifest file - the singleton certificate file in the root of the VNF package (if available in the package) - the signing certificates of the individual files included in the ZIP archive (if available in the package) - the singleton certificate file in the root of the VNF package (if available in the package) - the signing certificates of the individual files included in the ZIP archive (if available in the package) - the signatures of the individual files (if available in the package) Three examples are provided below. NOTE: These examples do not show the security related files. NOTE 3: These examples do not show the security related files. EXAMPLE 1: Assuming a request is sent for the following VNF package (as described in clause A.1 in ETSI GS NFV-SOL 004): Loading
