4 title: SOL003 - VNF Lifecycle Management interface
6 SOL003 - VNF Lifecycle Management interface definition
8 IMPORTANT: Please note that this file might be not aligned to the current version of the ETSI Group Specification it refers to. In case of discrepancies the published ETSI Group Specification takes precedence.
10 In clause 4.3.2 of ETSI GS NFV-SOL 003 v2.4.1, an attribute-based filtering mechanism is defined. This mechanism is currently not included in the corresponding OpenAPI design for this GS version. Changes to the attribute-based filtering mechanism are being considered in v2.5.1 of this GS for inclusion in the corresponding future ETSI NFV OpenAPI design.
11 Please report bugs to https://forge.etsi.org/bugzilla/buglist.cgi?component=Nfv-Openapis&list_id=61&product=NFV&resolution=
13 name: ETSI Forge copyright notice
14 url: 'https://forge.etsi.org/etsi-forge-copyright-notice.txt'
16 description: ETSI GS NFV-SOL 003 V2.4.1
17 url: 'http://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.04.01_60/gs_NFV-SOL003v020401p.pdf'
31 The POST method creates a new VNF instance resource.
35 - name: createVnfRequest
36 description: The VNF creation parameters
46 An identifier with the intention of being globally unique.
50 Human-readable name of the VNF instance to be created.
52 vnfInstanceDescription:
54 Human-readable description of the VNF instance to be created.
58 Content-Types that are acceptable for the response. Reference: IETF RFC 7231
64 The authorization token for the request. Reference: IETF RFC 7235
70 The MIME type of the body of the request. Reference: IETF RFC 7231
76 description: A VNF Instance identifier was created successfully
79 description: The MIME type of the body of the response.
84 description: The resource URI of the created VNF instance
89 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
95 This type represents a VNF instance.
109 An identifier with the intention of being globally unique.
113 Name of the VNF instance. This attribute can be modified with the PATCH method.
115 vnfInstanceDescription:
117 Human-readable description of the VNF instance. This attribute can be modified with the PATCH method.
121 An identifier with the intention of being globally unique.
125 Provider of the VNF and the VNFD. The value is copied from the VNFD.
129 Name to identify the VNF Product. The value is copied from the VNFD.
141 An identifier with the intention of being globally unique.
143 vnfConfigurableProperties:
145 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
149 Information about VIM connections to be used for managing the resources for the VNF instance. This attribute shall only be supported and present if VNF-related resource management in direct mode is applicable. This attribute can be modified with the PATCH method.
153 This type represents parameters to connect to a VIM for managing the resources of a VNF instance. This structure is used to convey VIM-related parameters over the Or-Vnfm interface. Additional parameters for a VIM may be configured into the VNFM by means outside the scope of the present document, and bound to the identifier of that VIM.
161 An identifier with the intention of being globally unique.
165 An identifier with the intention of being globally unique.
169 Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the "interfaceInfo" and "accessInfo" attributes, based on the type of the VIM. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM types. The structure of the registry is defined in Annex C of SOL003.
173 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
177 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
181 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
185 The instantiation state of the VNF.
192 Information specific to an instantiated VNF instance. This attribute shall be present if the instantiateState attribute value is INSTANTIATED.
200 An identifier that is unique within a VNF descriptor.
209 Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how "big" the VNF has been scaled w.r.t. that aspect.
219 An identifier that is unique within a VNF descriptor.
223 Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.
227 Information about the external CPs exposed by the VNF instance.
238 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
242 An identifier that is unique within a VNF descriptor.
246 Network protocol information for this CP.
250 This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.
256 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.
262 This type represents information about a network address that has been assigned.
269 A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.
274 Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet.
283 The type of the IP addresses. Permitted values: IPV4, IPV6.
290 Fixed addresses assigned (from the subnet defined by "subnetId" if provided).
294 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.
299 Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if "addresses" is present and shall be absent otherwise.
303 An IP address range used, e.g., in case of egress connections. Exactly one of "addresses" or "addressRange" shall be present.
311 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.
316 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.
321 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.
326 An identifier with the intention of being globally unique.
330 Information about the external VLs the VNF instance is connected to.
340 An identifier with the intention of being globally unique.
348 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
352 An identifier with the intention of being globally unique.
356 An identifier with the intention of being globally unique.
360 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
362 vimLevelResourceType:
364 Type of the resource in the scope of the VIM or the resource provider.
368 Link ports of this VL.
372 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.
380 An identifier with the intention of being globally unique.
388 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
392 An identifier with the intention of being globally unique.
396 An identifier with the intention of being globally unique.
400 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
402 vimLevelResourceType:
404 Type of the resource in the scope of the VIM or the resource provider.
408 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
410 extManagedVirtualLinkInfo:
412 External virtual links the VNF instance is connected to.
418 - vnfVirtualLinkDescId
422 An identifier with the intention of being globally unique.
424 vnfVirtualLinkDescId:
426 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
434 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
438 An identifier with the intention of being globally unique.
442 An identifier with the intention of being globally unique.
446 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
448 vimLevelResourceType:
450 Type of the resource in the scope of the VIM or the resource provider.
454 Link ports of this VL.
464 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
472 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
476 An identifier with the intention of being globally unique.
480 An identifier with the intention of being globally unique.
484 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
486 vimLevelResourceType:
488 Type of the resource in the scope of the VIM or the resource provider.
492 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
494 monitoringParameters:
496 Active monitoring parameters.
507 An identifier that is unique within a VNF descriptor.
511 Human readable name of the monitoring parameter, as defined in the VNFD.
515 Value of the monitoring parameter known to the VNFM (e.g. obtained for autoscaling purposes). The type of the "value" attribute (i.e. scalar, structure (Object in JSON), or array (of scalars, arrays or structures/Objects)) is assumed to be defined in an external measurement specification.
519 Represents the point in time when the measurement has been performed, as known to the VNFM. Should be formatted according to ETF RFC 3339.
521 localizationLanguage:
523 Information about localization language of the VNF (includes e.g. strings in the VNFD). The localization languages supported by a VNF can be declared in the VNFD, and localization language selection can take place at instantiation time. The value shall comply with the format defined in IETF RFC 5646.
527 Information about the virtualised compute and storage resources used by the VNFCs of the VNF instance.
531 This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance.
540 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
544 An identifier that is unique within a VNF descriptor.
552 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
556 An identifier with the intention of being globally unique.
560 An identifier with the intention of being globally unique.
564 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
566 vimLevelResourceType:
568 Type of the resource in the scope of the VIM or the resource provider.
572 References to the VirtualStorage resources. The value refers to a VirtualStorageResourceInfo item in the VnfInstance.
576 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
580 An identifier with the intention of being globally unique.
584 CPs of the VNFC instance. Shall be present when that particular CP of the VNFC instance is associated to an external CP of the VNF instance. May be present otherwise.
594 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
598 An identifier that is unique within a VNF descriptor.
602 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
606 Network protocol information for this CP.
610 This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.
616 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.
622 This type represents information about a network address that has been assigned.
629 A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.
634 Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet.
643 The type of the IP addresses. Permitted values: IPV4, IPV6.
650 Fixed addresses assigned (from the subnet defined by "subnetId" if provided).
654 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.
659 Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if "addresses" is present and shall be absent otherwise.
663 An IP address range used, e.g., in case of egress connections. Exactly one of "addresses" or "addressRange" shall be present.
671 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.
676 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.
681 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.
686 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
690 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
692 virtualLinkResourceInfo:
694 Information about the virtualised network resources used by the VLs of the VNF instance.
698 This type represents the information that allows addressing a virtualised resource that is used by an internal VL instance in a VNF instance.
702 - vnfVirtualLinkDescId
707 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
709 vnfVirtualLinkDescId:
711 An identifier that is unique within a VNF descriptor.
719 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
723 An identifier with the intention of being globally unique.
727 An identifier with the intention of being globally unique.
731 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
733 vimLevelResourceType:
735 Type of the resource in the scope of the VIM or the resource provider.
739 An identifier with the intention of being globally unique.
743 Links ports of this VL. Shall be present when the linkPort is used for external connectivity by the VNF (refer to VnfLinkPortInfo). May be present otherwise.
753 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
761 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
765 An identifier with the intention of being globally unique.
769 An identifier with the intention of being globally unique.
773 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
775 vimLevelResourceType:
777 Type of the resource in the scope of the VIM or the resource provider.
781 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
785 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
787 virtualStorageResourceInfo:
789 Information on the virtualised storage resource(s) used as storage for the VNF instance.
793 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance.
797 - virtualStorageDescId
802 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
804 virtualStorageDescId:
806 An identifier that is unique within a VNF descriptor.
814 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
818 An identifier with the intention of being globally unique.
822 An identifier with the intention of being globally unique.
826 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
828 vimLevelResourceType:
830 Type of the resource in the scope of the VIM or the resource provider.
834 An identifier with the intention of being globally unique.
838 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
842 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
846 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
850 Links to resources related to this resource.
857 This type represents a link to a resource.
864 URI of the referenced resource.
869 This type represents a link to a resource.
876 URI of the referenced resource.
881 This type represents a link to a resource.
888 URI of the referenced resource.
893 This type represents a link to a resource.
900 URI of the referenced resource.
905 This type represents a link to a resource.
912 URI of the referenced resource.
917 This type represents a link to a resource.
924 URI of the referenced resource.
929 This type represents a link to a resource.
936 URI of the referenced resource.
941 This type represents a link to a resource.
948 URI of the referenced resource.
953 This type represents a link to a resource.
960 URI of the referenced resource.
965 This type represents a link to a resource.
972 URI of the referenced resource.
978 If the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem.
981 If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
984 If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code.The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
987 description: The MIME type of the body of the response.
993 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
999 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
1007 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
1012 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
1016 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
1020 A human-readable explanation specific to this occurrence of the problem.
1024 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
1030 If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
1033 description: The MIME type of the body of the response.
1039 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
1045 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
1053 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
1058 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
1062 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
1066 A human-readable explanation specific to this occurrence of the problem.
1070 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
1076 If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it.
1079 description: The MIME type of the body of the response.
1085 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
1093 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
1098 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
1102 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
1106 A human-readable explanation specific to this occurrence of the problem.
1110 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
1116 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
1119 description: The MIME type of the body of the response.
1125 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
1133 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
1138 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
1142 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
1146 A human-readable explanation specific to this occurrence of the problem.
1150 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
1156 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
1159 description: The MIME type of the body of the response.
1165 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
1173 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
1178 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
1182 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
1186 A human-readable explanation specific to this occurrence of the problem.
1190 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
1196 If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted in that case.
1199 description: The MIME type of the body of the response.
1205 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
1213 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
1218 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
1222 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
1226 A human-readable explanation specific to this occurrence of the problem.
1230 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
1236 Another request is in progress that prohibits the fulfilment of the current request, or the current resource state is inconsistent with the request.
1239 description: The MIME type of the body of the response.
1245 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
1251 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
1259 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
1264 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
1268 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
1272 A human-readable explanation specific to this occurrence of the problem.
1276 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
1281 Requested Range Not Satisfiable
1282 This code is returned if the requested byte range in the Range HTTP header is not present in the requested resource.
1285 description: The MIME type of the body of the response.
1291 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
1299 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
1304 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
1308 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
1312 A human-readable explanation specific to this occurrence of the problem.
1316 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
1321 Unprocessable Entity
1322 If the payload body of a request contains syntactically correct data (e.g. well-formed JSON) but the data cannot be processed (e.g. because it fails validation against a schema), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem. NOTE 2: This error response code is only applicable for methods that have a request body.
1325 description: The MIME type of the body of the response.
1331 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
1339 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
1344 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
1348 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
1352 A human-readable explanation specific to this occurrence of the problem.
1356 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
1361 Internal Server Error
1362 If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond withthis response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
1365 description: The MIME type of the body of the response.
1371 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
1379 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
1384 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
1388 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
1392 A human-readable explanation specific to this occurrence of the problem.
1396 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
1402 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted.
1405 description: The MIME type of the body of the response.
1411 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
1419 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
1424 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
1428 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
1432 A human-readable explanation specific to this occurrence of the problem.
1436 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
1439 '/vnf_instances/{vnfInstanceId}':
1441 - name: vnfInstanceId
1443 Identifier of the VNF instance. This identifier can be retrieved from the resource referenced by the "Location" HTTP header in the response to a POST request creating a new VNF instance resource. It can also be retrieved from the "id" attribute in the payload body of that response.
1451 The GET method retrieves information about a VNF instance by reading an individual VNF instance resource.
1457 Content-Types that are acceptable for the response. Reference: IETF RFC 7231
1461 - name: Authorization
1463 The authorization token for the request. Reference: IETF RFC 7235
1467 - name: Content-Type
1469 The MIME type of the body of the request. Reference: IETF RFC 7231
1477 Information about zero or more VNF instances was queried successfully. The response body shall contain representations of zero or more VNF instances.
1480 description: The MIME type of the body of the response.
1486 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
1492 This type represents a VNF instance.
1499 - vnfSoftwareVersion
1502 - instantiationState
1506 An identifier with the intention of being globally unique.
1510 Name of the VNF instance. This attribute can be modified with the PATCH method.
1512 vnfInstanceDescription:
1514 Human-readable description of the VNF instance. This attribute can be modified with the PATCH method.
1518 An identifier with the intention of being globally unique.
1522 Provider of the VNF and the VNFD. The value is copied from the VNFD.
1526 Name to identify the VNF Product. The value is copied from the VNFD.
1538 An identifier with the intention of being globally unique.
1540 vnfConfigurableProperties:
1542 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
1546 Information about VIM connections to be used for managing the resources for the VNF instance. This attribute shall only be supported and present if VNF-related resource management in direct mode is applicable. This attribute can be modified with the PATCH method.
1550 This type represents parameters to connect to a VIM for managing the resources of a VNF instance. This structure is used to convey VIM-related parameters over the Or-Vnfm interface. Additional parameters for a VIM may be configured into the VNFM by means outside the scope of the present document, and bound to the identifier of that VIM.
1558 An identifier with the intention of being globally unique.
1562 An identifier with the intention of being globally unique.
1566 Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the "interfaceInfo" and "accessInfo" attributes, based on the type of the VIM. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM types. The structure of the registry is defined in Annex C of SOL003.
1570 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
1574 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
1578 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
1582 The instantiation state of the VNF.
1587 instantiatedVnfInfo:
1589 Information specific to an instantiated VNF instance. This attribute shall be present if the instantiateState attribute value is INSTANTIATED.
1597 An identifier that is unique within a VNF descriptor.
1606 Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how "big" the VNF has been scaled w.r.t. that aspect.
1616 An identifier that is unique within a VNF descriptor.
1620 Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.
1624 Information about the external CPs exposed by the VNF instance.
1635 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
1639 An identifier that is unique within a VNF descriptor.
1643 Network protocol information for this CP.
1647 This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.
1653 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.
1659 This type represents information about a network address that has been assigned.
1666 A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.
1671 Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet.
1680 The type of the IP addresses. Permitted values: IPV4, IPV6.
1687 Fixed addresses assigned (from the subnet defined by "subnetId" if provided).
1691 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.
1696 Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if "addresses" is present and shall be absent otherwise.
1700 An IP address range used, e.g., in case of egress connections. Exactly one of "addresses" or "addressRange" shall be present.
1708 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.
1713 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.
1718 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.
1723 An identifier with the intention of being globally unique.
1727 Information about the external VLs the VNF instance is connected to.
1737 An identifier with the intention of being globally unique.
1745 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
1749 An identifier with the intention of being globally unique.
1753 An identifier with the intention of being globally unique.
1757 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
1759 vimLevelResourceType:
1761 Type of the resource in the scope of the VIM or the resource provider.
1765 Link ports of this VL.
1769 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.
1777 An identifier with the intention of being globally unique.
1785 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
1789 An identifier with the intention of being globally unique.
1793 An identifier with the intention of being globally unique.
1797 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
1799 vimLevelResourceType:
1801 Type of the resource in the scope of the VIM or the resource provider.
1805 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
1807 extManagedVirtualLinkInfo:
1809 External virtual links the VNF instance is connected to.
1815 - vnfVirtualLinkDescId
1819 An identifier with the intention of being globally unique.
1821 vnfVirtualLinkDescId:
1823 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
1831 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
1835 An identifier with the intention of being globally unique.
1839 An identifier with the intention of being globally unique.
1843 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
1845 vimLevelResourceType:
1847 Type of the resource in the scope of the VIM or the resource provider.
1851 Link ports of this VL.
1861 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
1869 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
1873 An identifier with the intention of being globally unique.
1877 An identifier with the intention of being globally unique.
1881 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
1883 vimLevelResourceType:
1885 Type of the resource in the scope of the VIM or the resource provider.
1889 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
1891 monitoringParameters:
1893 Active monitoring parameters.
1904 An identifier that is unique within a VNF descriptor.
1908 Human readable name of the monitoring parameter, as defined in the VNFD.
1912 Value of the monitoring parameter known to the VNFM (e.g. obtained for autoscaling purposes). The type of the "value" attribute (i.e. scalar, structure (Object in JSON), or array (of scalars, arrays or structures/Objects)) is assumed to be defined in an external measurement specification.
1916 Represents the point in time when the measurement has been performed, as known to the VNFM. Should be formatted according to ETF RFC 3339.
1918 localizationLanguage:
1920 Information about localization language of the VNF (includes e.g. strings in the VNFD). The localization languages supported by a VNF can be declared in the VNFD, and localization language selection can take place at instantiation time. The value shall comply with the format defined in IETF RFC 5646.
1924 Information about the virtualised compute and storage resources used by the VNFCs of the VNF instance.
1928 This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance.
1937 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
1941 An identifier that is unique within a VNF descriptor.
1949 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
1953 An identifier with the intention of being globally unique.
1957 An identifier with the intention of being globally unique.
1961 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
1963 vimLevelResourceType:
1965 Type of the resource in the scope of the VIM or the resource provider.
1969 References to the VirtualStorage resources. The value refers to a VirtualStorageResourceInfo item in the VnfInstance.
1973 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
1977 An identifier with the intention of being globally unique.
1981 CPs of the VNFC instance. Shall be present when that particular CP of the VNFC instance is associated to an external CP of the VNF instance. May be present otherwise.
1991 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
1995 An identifier that is unique within a VNF descriptor.
1999 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
2003 Network protocol information for this CP.
2007 This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.
2013 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.
2019 This type represents information about a network address that has been assigned.
2026 A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.
2031 Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet.
2040 The type of the IP addresses. Permitted values: IPV4, IPV6.
2047 Fixed addresses assigned (from the subnet defined by "subnetId" if provided).
2051 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.
2056 Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if "addresses" is present and shall be absent otherwise.
2060 An IP address range used, e.g., in case of egress connections. Exactly one of "addresses" or "addressRange" shall be present.
2068 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.
2073 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.
2078 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.
2083 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
2087 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
2089 virtualLinkResourceInfo:
2091 Information about the virtualised network resources used by the VLs of the VNF instance.
2095 This type represents the information that allows addressing a virtualised resource that is used by an internal VL instance in a VNF instance.
2099 - vnfVirtualLinkDescId
2104 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
2106 vnfVirtualLinkDescId:
2108 An identifier that is unique within a VNF descriptor.
2116 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
2120 An identifier with the intention of being globally unique.
2124 An identifier with the intention of being globally unique.
2128 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
2130 vimLevelResourceType:
2132 Type of the resource in the scope of the VIM or the resource provider.
2136 An identifier with the intention of being globally unique.
2140 Links ports of this VL. Shall be present when the linkPort is used for external connectivity by the VNF (refer to VnfLinkPortInfo). May be present otherwise.
2150 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
2158 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
2162 An identifier with the intention of being globally unique.
2166 An identifier with the intention of being globally unique.
2170 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
2172 vimLevelResourceType:
2174 Type of the resource in the scope of the VIM or the resource provider.
2178 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
2182 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
2184 virtualStorageResourceInfo:
2186 Information on the virtualised storage resource(s) used as storage for the VNF instance.
2190 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance.
2194 - virtualStorageDescId
2199 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
2201 virtualStorageDescId:
2203 An identifier that is unique within a VNF descriptor.
2211 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
2215 An identifier with the intention of being globally unique.
2219 An identifier with the intention of being globally unique.
2223 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
2225 vimLevelResourceType:
2227 Type of the resource in the scope of the VIM or the resource provider.
2231 An identifier with the intention of being globally unique.
2235 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
2239 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
2243 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
2247 Links to resources related to this resource.
2254 This type represents a link to a resource.
2261 URI of the referenced resource.
2266 This type represents a link to a resource.
2273 URI of the referenced resource.
2278 This type represents a link to a resource.
2285 URI of the referenced resource.
2290 This type represents a link to a resource.
2297 URI of the referenced resource.
2302 This type represents a link to a resource.
2309 URI of the referenced resource.
2314 This type represents a link to a resource.
2321 URI of the referenced resource.
2326 This type represents a link to a resource.
2333 URI of the referenced resource.
2338 This type represents a link to a resource.
2345 URI of the referenced resource.
2350 This type represents a link to a resource.
2357 URI of the referenced resource.
2362 This type represents a link to a resource.
2369 URI of the referenced resource.
2375 If the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem.
2378 If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
2381 If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code.The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
2384 description: The MIME type of the body of the response.
2390 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
2396 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
2404 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
2409 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
2413 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
2417 A human-readable explanation specific to this occurrence of the problem.
2421 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
2427 If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
2430 description: The MIME type of the body of the response.
2436 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
2442 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
2450 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
2455 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
2459 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
2463 A human-readable explanation specific to this occurrence of the problem.
2467 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
2473 If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it.
2476 description: The MIME type of the body of the response.
2482 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
2490 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
2495 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
2499 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
2503 A human-readable explanation specific to this occurrence of the problem.
2507 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
2513 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
2516 description: The MIME type of the body of the response.
2522 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
2530 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
2535 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
2539 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
2543 A human-readable explanation specific to this occurrence of the problem.
2547 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
2553 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
2556 description: The MIME type of the body of the response.
2562 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
2570 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
2575 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
2579 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
2583 A human-readable explanation specific to this occurrence of the problem.
2587 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
2593 If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted in that case.
2596 description: The MIME type of the body of the response.
2602 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
2610 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
2615 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
2619 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
2623 A human-readable explanation specific to this occurrence of the problem.
2627 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
2633 Another request is in progress that prohibits the fulfilment of the current request, or the current resource state is inconsistent with the request.
2636 description: The MIME type of the body of the response.
2642 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
2648 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
2656 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
2661 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
2665 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
2669 A human-readable explanation specific to this occurrence of the problem.
2673 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
2678 Requested Range Not Satisfiable
2679 This code is returned if the requested byte range in the Range HTTP header is not present in the requested resource.
2682 description: The MIME type of the body of the response.
2688 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
2696 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
2701 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
2705 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
2709 A human-readable explanation specific to this occurrence of the problem.
2713 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
2718 Internal Server Error
2719 If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond withthis response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
2722 description: The MIME type of the body of the response.
2728 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
2736 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
2741 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
2745 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
2749 A human-readable explanation specific to this occurrence of the problem.
2753 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
2759 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted.
2762 description: The MIME type of the body of the response.
2768 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
2776 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
2781 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
2785 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
2789 A human-readable explanation specific to this occurrence of the problem.
2793 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
2798 Delete VNF Identifier
2800 This method deletes an individual VNF instance resource.
2804 - name: Authorization
2806 The authorization token for the request. Reference: IETF RFC 7235
2814 The VNF instance resource and the associated VNF identifier were deleted successfully. The response body shall be empty.
2818 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
2825 It fhe request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem. If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided. If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code.The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
2828 description: The MIME type of the body of the response.
2834 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
2840 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
2848 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
2853 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
2857 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
2861 A human-readable explanation specific to this occurrence of the problem.
2865 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
2871 If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
2874 description: The MIME type of the body of the response.
2880 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
2886 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
2894 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
2899 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
2903 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
2907 A human-readable explanation specific to this occurrence of the problem.
2911 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
2917 If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it.
2920 description: The MIME type of the body of the response.
2926 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
2934 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
2939 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
2943 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
2947 A human-readable explanation specific to this occurrence of the problem.
2951 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
2957 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
2960 description: The MIME type of the body of the response.
2966 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
2974 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
2979 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
2983 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
2987 A human-readable explanation specific to this occurrence of the problem.
2991 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
2997 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
3000 description: The MIME type of the body of the response.
3006 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
3014 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
3019 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
3023 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
3027 A human-readable explanation specific to this occurrence of the problem.
3031 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
3037 If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted in that case.
3040 description: The MIME type of the body of the response.
3046 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
3054 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
3059 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
3063 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
3067 A human-readable explanation specific to this occurrence of the problem.
3071 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
3077 The operation cannot be executed currently, due to a conflict with the state of the VNF instance resource. Typically, this is due to the fact that the VNF instance resource is in INSTANTIATED state. The response body shall contain a ProblemDetails structure, in which the "detail" attribute should convey more information about the error.
3080 description: The MIME type of the body of the response.
3086 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
3092 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
3100 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
3105 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
3109 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
3113 A human-readable explanation specific to this occurrence of the problem.
3117 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
3123 A precondition given in an HTTP request header is not fulfilled. Typically, this is due to an ETag mismatch, indicating that the resource was modified by another entity. The response body should contain a ProblemDetails structure, in which the "detail" attribute should convey more information about the error.
3126 description: The MIME type of the body of the response.
3132 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
3140 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
3145 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
3149 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
3153 A human-readable explanation specific to this occurrence of the problem.
3157 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
3162 Internal Server Error
3163 If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond withthis response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
3166 description: The MIME type of the body of the response.
3172 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
3180 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
3185 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
3189 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
3193 A human-readable explanation specific to this occurrence of the problem.
3197 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
3203 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted.
3206 description: The MIME type of the body of the response.
3212 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
3220 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
3225 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
3229 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
3233 A human-readable explanation specific to this occurrence of the problem.
3237 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
3240 '/vnf_instances/{vnfInstanceId}/instantiate':
3242 - name: vnfInstanceId
3244 Identifier of the VNF instance. This identifier can be retrieved from the resource referenced by the "Location" HTTP header in the response to a POST request creating a new VNF instance resource. It can also be retrieved from the "id" attribute in the payload body of that response.
3252 The POST method instantiates a VNF instance.
3256 - name: InstantiateVnfRequest
3257 description: Parameters for the VNF instantiation.
3267 An identifier that is unique within a VNF descriptor.
3271 Information about external VLs to connect the VNF to.
3275 This type represents an external VL.
3284 An identifier with the intention of being globally unique.
3288 An identifier with the intention of being globally unique.
3292 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
3296 External CPs of the VNF to be connected to this external VL.
3300 This type represents configuration information for external CPs created from a CPD.
3307 An identifier that is unique within a VNF descriptor.
3311 List of instance data that need to be configured on the CP instances created from the respective CPD.
3315 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.
3320 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
3324 An identifier with the intention of being globally unique.
3328 Parameters for configuring the network protocols on the link port that connects the CP to a VL. The following conditions apply to the attributes "linkPortId" and "cpProtocolData": * The "linkPortId" and "cpProtocolData" attributes shall both be absent for the deletion of an existing external CP instance
3329 addressed by cpInstanceId.
3330 * At least one of these attributes shall be present for a to-be-created external CP instance or an existing external
3332 * If the "linkPortId" attribute is absent, the VNFM shall create a link port.
3333 * If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided referencing a pre-created link port,
3334 and the VNFM can use means outside the scope of the present
3335 document to obtain the pre-configured address information for the
3336 connection point from the resource representing the link port.
3337 * If both "cpProtocolData" and "linkportId" are provided, the API consumer shall ensure that the cpProtocolData can be used with the
3338 pre-created link port referenced by "linkPortId".
3342 This type represents network protocol data.
3349 Identifier of layer(s) and protocol(s). 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.
3355 This type represents network address data for IP over Ethernet.
3360 A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.
3365 List of IP addresses to assign to the CP instance. Each entry represents IP address data for fixed or dynamic IP address assignment per subnet. If this attribute is not present, no IP address shall be assigned.
3374 The type of the IP addresses. Permitted values: IPV4, IPV6.
3381 Fixed addresses to assign (from the subnet defined by "subnetId" if provided). Exactly one of "fixedAddresses", "numDynamicAddresses" or "ipAddressRange" shall be present.
3385 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.
3388 numDynamicAddresses:
3390 Number of dynamic addresses to assign (from the subnet defined by "subnetId" if provided). Exactly one of "fixedAddresses", "numDynamicAddresses" or "ipAddressRange" shall be present.
3394 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.
3402 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.
3407 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.
3412 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
3416 Externally provided link ports to be used to connect external connection points to this external VL. If this attribute is not present, the VNFM shall create the link ports on the external VL.
3420 This type represents an externally provided link port to be used to connect an external connection point to an external VL.
3428 An identifier with the intention of being globally unique.
3436 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
3440 An identifier with the intention of being globally unique.
3444 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
3446 vimLevelResourceType:
3448 Type of the resource in the scope of the VIM or the resource provider.
3452 Information about VIM connections to be used for managing the resources for the VNF instance, or refer to external / externally-managed virtual links. This attribute shall only be supported and may be present if VNF-related resource management in direct mode is applicable.
3456 This type represents parameters to connect to a VIM for managing the resources of a VNF instance. This structure is used to convey VIM-related parameters over the Or-Vnfm interface. Additional parameters for a VIM may be configured into the VNFM by means outside the scope of the present document, and bound to the identifier of that VIM.
3464 An identifier with the intention of being globally unique.
3468 An identifier with the intention of being globally unique.
3472 Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the "interfaceInfo" and "accessInfo" attributes, based on the type of the VIM. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM types. The structure of the registry is defined in Annex C of SOL003.
3476 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
3480 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
3484 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
3488 Content-Types that are acceptable for the response. Reference: IETF RFC 7231
3492 - name: Authorization
3494 The authorization token for the request. Reference: IETF RFC 7235
3498 - name: Content-Type
3500 The MIME type of the body of the request. Reference: IETF RFC 7231
3508 The request was accepted for processing, but the processing has not been completed. The response body shall be empty. The HTTP response shall include a "Location" HTTP header that contains the URI of the newly-created "VNF LCM operation occurrence" resource corresponding to the operation.
3511 description: The resource URI of the created VNF instance
3516 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
3523 If the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem.
3526 If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
3529 If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code.The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
3532 description: The MIME type of the body of the response.
3538 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
3544 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
3552 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
3557 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
3561 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
3565 A human-readable explanation specific to this occurrence of the problem.
3569 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
3575 If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
3578 description: The MIME type of the body of the response.
3584 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
3590 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
3598 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
3603 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
3607 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
3611 A human-readable explanation specific to this occurrence of the problem.
3615 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
3621 If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it.
3624 description: The MIME type of the body of the response.
3630 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
3638 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
3643 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
3647 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
3651 A human-readable explanation specific to this occurrence of the problem.
3655 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
3661 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
3664 description: The MIME type of the body of the response.
3670 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
3678 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
3683 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
3687 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
3691 A human-readable explanation specific to this occurrence of the problem.
3695 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
3701 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
3704 description: The MIME type of the body of the response.
3710 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
3718 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
3723 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
3727 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
3731 A human-readable explanation specific to this occurrence of the problem.
3735 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
3741 If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted in that case.
3744 description: The MIME type of the body of the response.
3750 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
3758 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
3763 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
3767 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
3771 A human-readable explanation specific to this occurrence of the problem.
3775 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
3781 The operation cannot be executed currently, due to a conflict with the state of the VNF instance resource. Typically, this is due to the fact that the VNF instance resource is in INSTANTIATED state. The response body shall contain a ProblemDetails structure, in which the "detail" attribute should convey more information about the error.
3784 description: The MIME type of the body of the response.
3790 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
3796 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
3804 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
3809 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
3813 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
3817 A human-readable explanation specific to this occurrence of the problem.
3821 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
3826 Requested Range Not Satisfiable
3827 This code is returned if the requested byte range in the Range HTTP header is not present in the requested resource.
3830 description: The MIME type of the body of the response.
3836 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
3844 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
3849 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
3853 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
3857 A human-readable explanation specific to this occurrence of the problem.
3861 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
3866 Internal Server Error
3867 If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond withthis response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
3870 description: The MIME type of the body of the response.
3876 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
3884 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
3889 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
3893 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
3897 A human-readable explanation specific to this occurrence of the problem.
3901 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
3907 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted.
3910 description: The MIME type of the body of the response.
3916 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
3924 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
3929 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
3933 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
3937 A human-readable explanation specific to this occurrence of the problem.
3941 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
3944 '/vnf_instances/{vnfInstanceId}/terminate':
3946 - name: vnfInstanceId
3948 The identifier of the VNF instance to be terminated. This identifier can be retrieved from the resource referenced by the "Location" HTTP header in the response to a POST request creating a new VNF instance resource. It can also be retrieved from the "id" attribute in the payload body of that response.
3956 The POST method terminates a VNF instance.
3960 - name: TerminateVnfRequest
3961 description: Parameters for the VNF termination.
3971 Indicates whether forceful or graceful termination is requested. VNFM Adapter will only support FORCEFUL in Dublin.
3978 Content-Types that are acceptable for the response. Reference: IETF RFC 7231
3982 - name: Authorization
3984 The authorization token for the request. Reference: IETF RFC 7235
3988 - name: Content-Type
3990 The MIME type of the body of the request. Reference: IETF RFC 7231
3998 The request was accepted for processing, but the processing has not been completed. On success, the HTTP response shall include a "Location" HTTP header that contains the URI of the newly-created "VNF LCM operation occurrence" resource corresponding to the operation.
4001 description: The MIME type of the body of the response.
4006 description: The resource URI of the created VNF instance
4011 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
4017 This type represents a VNF instance.
4024 - vnfSoftwareVersion
4027 - instantiationState
4031 An identifier with the intention of being globally unique.
4035 Name of the VNF instance. This attribute can be modified with the PATCH method.
4037 vnfInstanceDescription:
4039 Human-readable description of the VNF instance. This attribute can be modified with the PATCH method.
4043 An identifier with the intention of being globally unique.
4047 Provider of the VNF and the VNFD. The value is copied from the VNFD.
4051 Name to identify the VNF Product. The value is copied from the VNFD.
4063 An identifier with the intention of being globally unique.
4065 vnfConfigurableProperties:
4067 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
4071 Information about VIM connections to be used for managing the resources for the VNF instance. This attribute shall only be supported and present if VNF-related resource management in direct mode is applicable. This attribute can be modified with the PATCH method.
4075 This type represents parameters to connect to a VIM for managing the resources of a VNF instance. This structure is used to convey VIM-related parameters over the Or-Vnfm interface. Additional parameters for a VIM may be configured into the VNFM by means outside the scope of the present document, and bound to the identifier of that VIM.
4083 An identifier with the intention of being globally unique.
4087 An identifier with the intention of being globally unique.
4091 Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the "interfaceInfo" and "accessInfo" attributes, based on the type of the VIM. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM types. The structure of the registry is defined in Annex C of SOL003.
4095 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
4099 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
4103 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
4107 The instantiation state of the VNF.
4112 instantiatedVnfInfo:
4114 Information specific to an instantiated VNF instance. This attribute shall be present if the instantiateState attribute value is INSTANTIATED.
4122 An identifier that is unique within a VNF descriptor.
4131 Scale status of the VNF, one entry per aspect. Represents for every scaling aspect how "big" the VNF has been scaled w.r.t. that aspect.
4141 An identifier that is unique within a VNF descriptor.
4145 Indicates the scale level. The minimum value shall be 0 and the maximum value shall be <= maxScaleLevel as described in the VNFD.
4149 Information about the external CPs exposed by the VNF instance.
4160 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
4164 An identifier that is unique within a VNF descriptor.
4168 Network protocol information for this CP.
4172 This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.
4178 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.
4184 This type represents information about a network address that has been assigned.
4191 A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.
4196 Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet.
4205 The type of the IP addresses. Permitted values: IPV4, IPV6.
4212 Fixed addresses assigned (from the subnet defined by "subnetId" if provided).
4216 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.
4221 Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if "addresses" is present and shall be absent otherwise.
4225 An IP address range used, e.g., in case of egress connections. Exactly one of "addresses" or "addressRange" shall be present.
4233 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.
4238 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.
4243 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.
4248 An identifier with the intention of being globally unique.
4252 Information about the external VLs the VNF instance is connected to.
4262 An identifier with the intention of being globally unique.
4270 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
4274 An identifier with the intention of being globally unique.
4278 An identifier with the intention of being globally unique.
4282 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
4284 vimLevelResourceType:
4286 Type of the resource in the scope of the VIM or the resource provider.
4290 Link ports of this VL.
4294 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.
4302 An identifier with the intention of being globally unique.
4310 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
4314 An identifier with the intention of being globally unique.
4318 An identifier with the intention of being globally unique.
4322 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
4324 vimLevelResourceType:
4326 Type of the resource in the scope of the VIM or the resource provider.
4330 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
4332 extManagedVirtualLinkInfo:
4334 External virtual links the VNF instance is connected to.
4340 - vnfVirtualLinkDescId
4344 An identifier with the intention of being globally unique.
4346 vnfVirtualLinkDescId:
4348 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
4356 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
4360 An identifier with the intention of being globally unique.
4364 An identifier with the intention of being globally unique.
4368 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
4370 vimLevelResourceType:
4372 Type of the resource in the scope of the VIM or the resource provider.
4376 Link ports of this VL.
4386 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
4394 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
4398 An identifier with the intention of being globally unique.
4402 An identifier with the intention of being globally unique.
4406 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
4408 vimLevelResourceType:
4410 Type of the resource in the scope of the VIM or the resource provider.
4414 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
4416 monitoringParameters:
4418 Active monitoring parameters.
4429 An identifier that is unique within a VNF descriptor.
4433 Human readable name of the monitoring parameter, as defined in the VNFD.
4437 Value of the monitoring parameter known to the VNFM (e.g. obtained for autoscaling purposes). The type of the "value" attribute (i.e. scalar, structure (Object in JSON), or array (of scalars, arrays or structures/Objects)) is assumed to be defined in an external measurement specification.
4441 Represents the point in time when the measurement has been performed, as known to the VNFM. Should be formatted according to ETF RFC 3339.
4443 localizationLanguage:
4445 Information about localization language of the VNF (includes e.g. strings in the VNFD). The localization languages supported by a VNF can be declared in the VNFD, and localization language selection can take place at instantiation time. The value shall comply with the format defined in IETF RFC 5646.
4449 Information about the virtualised compute and storage resources used by the VNFCs of the VNF instance.
4453 This type represents the information on virtualised compute and storage resources used by a VNFC in a VNF instance.
4462 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
4466 An identifier that is unique within a VNF descriptor.
4474 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
4478 An identifier with the intention of being globally unique.
4482 An identifier with the intention of being globally unique.
4486 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
4488 vimLevelResourceType:
4490 Type of the resource in the scope of the VIM or the resource provider.
4494 References to the VirtualStorage resources. The value refers to a VirtualStorageResourceInfo item in the VnfInstance.
4498 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
4502 An identifier with the intention of being globally unique.
4506 CPs of the VNFC instance. Shall be present when that particular CP of the VNFC instance is associated to an external CP of the VNF instance. May be present otherwise.
4516 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
4520 An identifier that is unique within a VNF descriptor.
4524 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
4528 Network protocol information for this CP.
4532 This type describes the protocol layer(s) that a CP uses together with protocol-related information, like addresses.
4538 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.
4544 This type represents information about a network address that has been assigned.
4551 A MAC address. Representation: string that consists of groups of two hexadecimal digits, separated by hyphens or colons.
4556 Addresses assigned to the CP instance. Each entry represents IP addresses assigned by fixed or dynamic IP address assignment per subnet.
4565 The type of the IP addresses. Permitted values: IPV4, IPV6.
4572 Fixed addresses assigned (from the subnet defined by "subnetId" if provided).
4576 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.
4581 Indicates whether this set of addresses was assigned dynamically (true) or based on address information provided as input from the API consumer (false). Shall be present if "addresses" is present and shall be absent otherwise.
4585 An IP address range used, e.g., in case of egress connections. Exactly one of "addresses" or "addressRange" shall be present.
4593 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.
4598 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.
4603 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.
4608 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
4612 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
4614 virtualLinkResourceInfo:
4616 Information about the virtualised network resources used by the VLs of the VNF instance.
4620 This type represents the information that allows addressing a virtualised resource that is used by an internal VL instance in a VNF instance.
4624 - vnfVirtualLinkDescId
4629 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
4631 vnfVirtualLinkDescId:
4633 An identifier that is unique within a VNF descriptor.
4641 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
4645 An identifier with the intention of being globally unique.
4649 An identifier with the intention of being globally unique.
4653 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
4655 vimLevelResourceType:
4657 Type of the resource in the scope of the VIM or the resource provider.
4661 An identifier with the intention of being globally unique.
4665 Links ports of this VL. Shall be present when the linkPort is used for external connectivity by the VNF (refer to VnfLinkPortInfo). May be present otherwise.
4675 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
4683 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
4687 An identifier with the intention of being globally unique.
4691 An identifier with the intention of being globally unique.
4695 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
4697 vimLevelResourceType:
4699 Type of the resource in the scope of the VIM or the resource provider.
4703 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
4707 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
4709 virtualStorageResourceInfo:
4711 Information on the virtualised storage resource(s) used as storage for the VNF instance.
4715 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance.
4719 - virtualStorageDescId
4724 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
4726 virtualStorageDescId:
4728 An identifier that is unique within a VNF descriptor.
4736 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
4740 An identifier with the intention of being globally unique.
4744 An identifier with the intention of being globally unique.
4748 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
4750 vimLevelResourceType:
4752 Type of the resource in the scope of the VIM or the resource provider.
4756 An identifier with the intention of being globally unique.
4760 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
4764 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
4768 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
4772 Links to resources related to this resource.
4779 This type represents a link to a resource.
4786 URI of the referenced resource.
4791 This type represents a link to a resource.
4798 URI of the referenced resource.
4803 This type represents a link to a resource.
4810 URI of the referenced resource.
4815 This type represents a link to a resource.
4822 URI of the referenced resource.
4827 This type represents a link to a resource.
4834 URI of the referenced resource.
4839 This type represents a link to a resource.
4846 URI of the referenced resource.
4851 This type represents a link to a resource.
4858 URI of the referenced resource.
4863 This type represents a link to a resource.
4870 URI of the referenced resource.
4875 This type represents a link to a resource.
4882 URI of the referenced resource.
4887 This type represents a link to a resource.
4894 URI of the referenced resource.
4900 If the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem.
4903 If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
4906 If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code.The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
4909 description: The MIME type of the body of the response.
4915 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
4921 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
4929 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
4934 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
4938 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
4942 A human-readable explanation specific to this occurrence of the problem.
4946 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
4952 If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
4955 description: The MIME type of the body of the response.
4961 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
4967 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
4975 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
4980 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
4984 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
4988 A human-readable explanation specific to this occurrence of the problem.
4992 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
4998 If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it.
5001 description: The MIME type of the body of the response.
5007 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
5015 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
5020 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
5024 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
5028 A human-readable explanation specific to this occurrence of the problem.
5032 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
5038 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
5041 description: The MIME type of the body of the response.
5047 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
5055 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
5060 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
5064 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
5068 A human-readable explanation specific to this occurrence of the problem.
5072 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
5078 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
5081 description: The MIME type of the body of the response.
5087 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
5095 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
5100 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
5104 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
5108 A human-readable explanation specific to this occurrence of the problem.
5112 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
5118 If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted in that case.
5121 description: The MIME type of the body of the response.
5127 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
5135 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
5140 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
5144 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
5148 A human-readable explanation specific to this occurrence of the problem.
5152 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
5158 The operation cannot be executed currently, due to a conflict with the state of the VNF instance resource. Typically, this is due to the fact that the VNF instance resource is in NOT-INSTANTIATED state, or that another lifecycle management operation is ongoing. The response body shall contain a ProblemDetails structure, in which the "detail" attribute should convey more information about the error.
5161 description: The MIME type of the body of the response.
5167 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
5173 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
5181 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
5186 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
5190 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
5194 A human-readable explanation specific to this occurrence of the problem.
5198 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
5203 Internal Server Error
5204 If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond withthis response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
5207 description: The MIME type of the body of the response.
5213 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
5221 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
5226 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
5230 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
5234 A human-readable explanation specific to this occurrence of the problem.
5238 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
5244 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted.
5247 description: The MIME type of the body of the response.
5253 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
5261 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
5266 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
5270 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
5274 A human-readable explanation specific to this occurrence of the problem.
5278 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
5281 '/vnf_lcm_op_occs/{vnfLcmOpOccId}':
5283 - name: vnfLcmOpOccId
5285 Identifier of a VNF lifecycle management operation occurrence. This identifier can be retrieved from the resource referenced by the "Location" HTTP header in the response to a PATCH or POST request triggering a VNF LCM operation. It can also be retrieved from the "vnfLcmOpOccId" attribute in the VnfLcmOperationOccurrenceNotification.
5291 Get Operation Status
5293 The client can use this method to retrieve status information about a VNF lifecycle management operation occurrence by reading an individual "VNF LCM operation occurrence" resource.
5299 Content-Types that are acceptable for the response. Reference: IETF RFC 7231
5303 - name: Authorization
5305 The authorization token for the request. Reference: IETF RFC 7235
5313 Information about an individual VNF instance was queried successfully. The response body shall contain status information about a VNF lifecycle management operation occurrence.
5316 description: The MIME type of the body of the response.
5322 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
5328 This type represents a VNF lifecycle management operation occurrence.
5337 - isAutomaticInvocation
5343 An identifier with the intention of being globally unique.
5347 Value | Description ------|------------ STARTING | The LCM operation is starting. PROCESSING | The LCM operation is currently in execution. COMPLETED | he LCM operation has been completed successfully. FAILED_TEMP | The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED | The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK | The LCM operation is currently being rolled back. ROLLED_BACK | The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.
5359 Date-time when the current state was entered.
5364 Date-time of the start of the operation.
5369 An identifier with the intention of being globally unique.
5373 An identifier with the intention of being globally unique.
5377 Value | Description ------|------------ INSTANTIATE | Represents the "Instantiate VNF" LCM operation. SCALE | Represents the "Scale VNF" LCM operation. SCALE_TO_LEVEL | Represents the "Scale VNF to Level" LCM operation. CHANGE_FLAVOUR | Represents the "Change VNF Flavour" LCM operation. TERMINATE | Represents the "Terminate VNF" LCM operation. HEAL | Represents the "Heal VNF" LCM operation. OPERATE | Represents the "Operate VNF" LCM operation. CHANGE_EXT_CONN | Represents the "Change external VNF connectivity" LCM operation. MODIFY_INFO | Represents the "Modify VNF Information" LCM operation.
5389 isAutomaticInvocation:
5391 Set to true if this VNF LCM operation occurrence has been triggered by an automated procedure inside the VNFM (i.e. ScaleVnf / ScaleVnfToLevel triggered by auto-scale, or HealVnf triggered by auto-heal). Set to false otherwise.
5395 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
5399 If the VNF LCM operation occurrence is in "STARTING", "PROCESSING" or "ROLLING_BACK" state and the operation is being cancelled, this attribute shall be set to true. Otherwise, it shall be set to false.
5403 Cancellation mode. GRACEFUL: If the VNF LCM operation occurrence is in "PROCESSING" or "ROLLING_BACK" state, the VNFM shall not start any new resource management operation and shall wait for the ongoing resource management operations in the underlying system, typically the VIM, to finish execution or to time out. After that, the VNFM shall put the operation occurrence into the FAILED_TEMP state. If the VNF LCM operation occurrence is in "STARTING" state, the VNFM shall not start any resource management operation and shall wait for the granting request to finish execution or time out. After that, the VNFM shall put the operation occurrence into the ROLLED_BACK state. FORCEFUL: If the VNF LCM operation occurrence is in "PROCESSING" or "ROLLING_BACK" state, the VNFM shall not start any new resource management operation, shall cancel the ongoing resource management operations in the underlying system, typically the VIM, and shall wait for the cancellation to finish or to time out. After that, the VNFM shall put the operation occurrence into the FAILED_TEMP state. If the VNF LCM operation occurrence is in "STARTING" state, the VNFM shall not start any resource management operation and put the operation occurrence into the ROLLED_BACK state.
5410 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
5418 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
5423 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
5427 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
5431 A human-readable explanation specific to this occurrence of the problem.
5435 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
5440 This attribute contains information about the cumulative changes to virtualised resources that were performed so far by the LCM operation since its start, if applicable.
5445 Information about VNFC instances that were affected during the lifecycle operation. 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.
5449 This type provides information about added, deleted, modified and temporary VNFCs.
5459 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
5463 An identifier that is unique within a VNF descriptor.
5467 Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVnfc structure exists as long as the temporary resource exists.
5480 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
5484 An identifier with the intention of being globally unique.
5488 An identifier with the intention of being globally unique.
5492 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
5494 vimLevelResourceType:
5496 Type of the resource in the scope of the VIM or the resource provider.
5500 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
5504 Identifiers of CP(s) of the VNFC instance that were affected by the change. Shall be present for those affected CPs of the VNFC instance that are associated to an external CP of the VNF instance. May be present for further affected CPs of the VNFC instance.
5508 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
5510 addedStorageResourceIds:
5512 References to VirtualStorage resources that have been added. Each value refers to a VirtualStorageResourceInfo item in the VnfInstance that was added to the VNFC. It shall be provided if at least one storage resource was added to the VNFC.
5516 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
5518 removedStorageResourceIds:
5520 References to VirtualStorage resources that have been removed. The value contains the identifier of a VirtualStorageResourceInfo item that has been removed from the VNFC, and might no longer exist in the VnfInstance. It shall be provided if at least one storage resource was removed from the VNFC.
5524 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
5526 affectedVirtualLinks:
5528 Information about VL instances that were affected during the lifecycle operation. 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.
5532 This type provides information about added, deleted, modified and temporary VLs.
5542 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
5546 An identifier that is unique within a VNF descriptor.
5550 Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY * LINK_PORT_ADDED * LINK_PORT_REMOVED For a temporary resource, an AffectedVirtualLink structure exists as long as the temporary resource exists.
5565 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
5569 An identifier with the intention of being globally unique.
5573 An identifier with the intention of being globally unique.
5577 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
5579 vimLevelResourceType:
5581 Type of the resource in the scope of the VIM or the resource provider.
5585 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
5587 affectedVirtualStorages:
5589 Information about virtualised storage instances that were affected during the lifecycle operation. 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.
5593 This type provides information about added, deleted, modified and temporary virtual storage resources.
5597 - virtualStorageDescId
5603 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
5605 virtualStorageDescId:
5607 An identifier that is unique within a VNF descriptor.
5611 Signals the type of change. Permitted values: * ADDED * REMOVED * MODIFIED * TEMPORARY For a temporary resource, an AffectedVirtualStorage structure exists as long as the temporary resource exists.
5624 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
5628 An identifier with the intention of being globally unique.
5632 An identifier with the intention of being globally unique.
5636 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
5638 vimLevelResourceType:
5640 Type of the resource in the scope of the VIM or the resource provider.
5644 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
5648 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.
5653 If present, this attribute signals modifications of the "vnfInstanceName" attribute in "VnfInstance".
5655 vnfInstanceDescription:
5657 If present, this attribute signals modifications of the "vnfInstanceDescription" attribute in "VnfInstance".
5659 vnfConfigurableProperties:
5661 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
5665 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
5669 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
5673 If present, this attribute signals modifications of certain entries in the "vimConnectionInfo" attribute array in "VnfInstance".
5677 This type represents parameters to connect to a VIM for managing the resources of a VNF instance. This structure is used to convey VIM-related parameters over the Or-Vnfm interface. Additional parameters for a VIM may be configured into the VNFM by means outside the scope of the present document, and bound to the identifier of that VIM.
5685 An identifier with the intention of being globally unique.
5689 An identifier with the intention of being globally unique.
5693 Discriminator for the different types of the VIM information. The value of this attribute determines the structure of the "interfaceInfo" and "accessInfo" attributes, based on the type of the VIM. The set of permitted values is expected to change over time as new types or versions of VIMs become available. The ETSI NFV registry of VIM-related information provides access to information about VimConnectionInfo definitions for various VIM types. The structure of the registry is defined in Annex C of SOL003.
5697 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
5701 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
5705 This type represents a list of key-value pairs. The order of the pairs in the list is not significant. In JSON, a set of key- value pairs is represented as an object. It shall comply with the provisions defined in clause 4 of IETF RFC 7159.
5709 An identifier with the intention of being globally unique.
5713 An identifier with the intention of being globally unique.
5717 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.
5721 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.
5731 changedExtConnectivity:
5733 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.
5743 An identifier with the intention of being globally unique.
5751 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
5755 An identifier with the intention of being globally unique.
5759 An identifier with the intention of being globally unique.
5763 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
5765 vimLevelResourceType:
5767 Type of the resource in the scope of the VIM or the resource provider.
5771 Link ports of this VL.
5775 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.
5783 An identifier with the intention of being globally unique.
5791 This type represents the information that allows addressing a virtualised resource that is used by a VNF instance. Information about the resource is available from the VIM.
5795 An identifier with the intention of being globally unique.
5799 An identifier with the intention of being globally unique.
5803 An identifier maintained by the VIM or other resource provider. It is expected to be unique within the VIM instance.
5805 vimLevelResourceType:
5807 Type of the resource in the scope of the VIM or the resource provider.
5811 An identifier that is unique for the respective type within a VNF instance, but may not be globally unique.
5815 Links to resources related to this resource.
5823 This type represents a link to a resource.
5830 URI of the referenced resource.
5835 This type represents a link to a resource.
5842 URI of the referenced resource.
5847 This type represents a link to a resource.
5854 URI of the referenced resource.
5859 This type represents a link to a resource.
5866 URI of the referenced resource.
5871 This type represents a link to a resource.
5878 URI of the referenced resource.
5883 This type represents a link to a resource.
5890 URI of the referenced resource.
5895 This type represents a link to a resource.
5902 URI of the referenced resource.
5908 If the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem.
5911 If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
5914 If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code.The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
5917 description: The MIME type of the body of the response.
5923 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
5929 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
5937 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
5942 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
5946 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
5950 A human-readable explanation specific to this occurrence of the problem.
5954 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
5960 If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
5963 description: The MIME type of the body of the response.
5969 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
5975 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
5983 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
5988 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
5992 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
5996 A human-readable explanation specific to this occurrence of the problem.
6000 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
6006 If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it.
6009 description: The MIME type of the body of the response.
6015 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
6023 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
6028 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
6032 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
6036 A human-readable explanation specific to this occurrence of the problem.
6040 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
6046 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
6049 description: The MIME type of the body of the response.
6055 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
6063 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
6068 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
6072 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
6076 A human-readable explanation specific to this occurrence of the problem.
6080 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
6086 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
6089 description: The MIME type of the body of the response.
6095 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
6103 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
6108 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
6112 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
6116 A human-readable explanation specific to this occurrence of the problem.
6120 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
6126 If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted in that case.
6129 description: The MIME type of the body of the response.
6135 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
6143 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
6148 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
6152 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
6156 A human-readable explanation specific to this occurrence of the problem.
6160 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
6166 Another request is in progress that prohibits the fulfilment of the current request, or the current resource state is inconsistent with the request.
6169 description: The MIME type of the body of the response.
6175 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
6181 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
6189 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
6194 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
6198 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
6202 A human-readable explanation specific to this occurrence of the problem.
6206 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
6211 Internal Server Error
6212 If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond withthis response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
6215 description: The MIME type of the body of the response.
6221 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
6229 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
6234 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
6238 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
6242 A human-readable explanation specific to this occurrence of the problem.
6246 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
6252 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted.
6255 description: The MIME type of the body of the response.
6261 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
6269 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
6274 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
6278 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
6282 A human-readable explanation specific to this occurrence of the problem.
6286 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
6294 The POST method creates a new subscription. Creation of two subscription resources with the same callbackURI and the same filter can result in performance degradation and will provide duplicates of notifications to the NFVO, and might make sense only in very rare use cases. Consequently, the VNFM may either allow creating a subscription resource if another subscription resource with the same filter and callbackUri already exists (in which case it shall return the “201 Created” response code), or may decide to not create a duplicate subscription resource (in which case it shall return a “303 See Other” response code referencing the existing subscription resource with the same filter and callbackUri).
6298 - name: LccnSubscriptionRequest
6300 Details of the subscription to be created.
6305 This type represents a subscription request related to notifications about VNF lifecycle changes.
6312 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).
6315 vnfInstanceSubscriptionFilter:
6317 This type represents subscription filter criteria to match VNF instances.
6322 If present, match VNF instances with an instance identifier listed in this attribute. The attributes "vnfInstanceIds" and "vnfInstanceNames" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.
6326 An identifier with the intention of being globally unique.
6330 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.
6335 - VnfLcmOperationOccurrenceNotification
6336 - VnfIdentifierCreationNotification
6337 - VnfIdentifierDeletionNotification
6340 Match particular VNF lifecycle operation types for the notification of type VnfLcmOperationOccurrenceNotification. May be present if the "notificationTypes" attribute contains the value "VnfLcmOperationOccurrenceNotification", and shall be absent otherwise.
6344 Value | Description ------|------------ INSTANTIATE | Represents the "Instantiate VNF" LCM operation. SCALE | Represents the "Scale VNF" LCM operation. SCALE_TO_LEVEL | Represents the "Scale VNF to Level" LCM operation. CHANGE_FLAVOUR | Represents the "Change VNF Flavour" LCM operation. TERMINATE | Represents the "Terminate VNF" LCM operation. HEAL | Represents the "Heal VNF" LCM operation. OPERATE | Represents the "Operate VNF" LCM operation. CHANGE_EXT_CONN | Represents the "Change external VNF connectivity" LCM operation. MODIFY_INFO | Represents the "Modify VNF Information" LCM operation.
6351 Match particular LCM operation state values as reported in notifications of type VnfLcmOperationOccurrenceNotification. May be present if the "notificationTypes" attribute contains the value "VnfLcmOperationOccurrenceNotification", and shall be absent otherwise.
6355 Value | Description ------|------------ STARTING | The LCM operation is starting. PROCESSING | The LCM operation is currently in execution. COMPLETED | he LCM operation has been completed successfully. FAILED_TEMP | The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED | The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK | The LCM operation is currently being rolled back. ROLLED_BACK | The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.
6367 String formatted according to IETF RFC 3986.
6376 Defines the types of Authentication / Authorization which the API consumer is willing to accept when receiving a notification. Permitted values: * BASIC: In every HTTP request to the notification endpoint, use HTTP Basic authentication with the client credentials.
6377 * OAUTH2_CLIENT_CREDENTIALS: In every HTTP request to the notification endpoint, use an OAuth 2.0 Bearer token, obtained
6378 using the client credentials grant type.
6379 * TLS_CERT: Every HTTP request to the notification endpoint is sent over a mutually authenticated TLS session, i.e. not only the
6380 server is authenticated, but also the client is authenticated
6381 during the TLS tunnel setup.
6387 - OAUTH2_CLIENT_CREDENTIALS
6391 Parameters for authentication/authorization using BASIC. Shall be present if authType is "BASIC" and the contained information has not been provisioned out of band. Shall be absent otherwise.
6396 Username to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.
6400 Password to be used in HTTP Basic authentication. Shall be present if it has not been provisioned out of band.
6402 paramsOauth2ClientCredentials:
6404 Parameters for authentication/authorization using OAUTH2_CLIENT_CREDENTIALS. Shall be present if authType is "OAUTH2_CLIENT_CREDENTIALS" and the contained information has not been provisioned out of band. Shall be absent otherwise.
6409 Client identifier to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between subscriptions. The value of clientPassword should be generated by a random process.
6413 Client password to be used in the access token request of the OAuth 2.0 client credentials grant type. Shall be present if it has not been provisioned out of band. The clientId and clientPassword passed in a subscription shall not be the same as the clientId and clientPassword that are used to obtain authorization for API requests. Client credentials may differ between subscriptions. The value of clientPassword should be generated by a random process.
6417 String formatted according to IETF RFC 3986.
6421 Content-Types that are acceptable for the response. Reference: IETF RFC 7231
6425 - name: Authorization
6427 The authorization token for the request. Reference: IETF RFC 7235
6431 - name: Content-Type
6433 The MIME type of the body of the request. Reference: IETF RFC 7231
6441 The subscription was created successfully. The response body shall contain a representation of the created subscription resource. The HTTP response shall include a "Location" HTTP header that points to the created subscription resource.
6444 description: The MIME type of the body of the response.
6449 description: The resource URI of the created VNF instance
6454 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
6460 This type represents a subscription related to notifications about VNF lifecycle changes.
6469 An identifier with the intention of being globally unique.
6473 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).
6476 vnfInstanceSubscriptionFilter:
6478 This type represents subscription filter criteria to match VNF instances.
6483 If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. The attributes "vnfdIds" and "vnfProductsFromProviders" are alternatives to reference to VNF instances that are based on certain VNFDs in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.
6487 An identifier with the intention of being globally unique.
6489 vnfProductsFromProviders:
6491 If present, match VNF instances that belong to VNF products from certain providers. The attributes "vnfdIds" and "vnfProductsFromProviders" are alternatives to reference to VNF instances that are based on certain VNFDs in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.
6500 Name of the VNF provider to match.
6504 If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.
6513 Name of the VNF product to match.
6517 If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.
6522 - vnfSoftwareVersion
6530 If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.
6538 If present, match VNF instances with an instance identifier listed in this attribute. The attributes "vnfInstanceIds" and "vnfInstanceNames" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.
6542 An identifier with the intention of being globally unique.
6546 If present, match VNF instances with a VNF Instance Name listed in this attribute. The attributes "vnfInstanceIds" and "vnfInstanceNames" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.
6552 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.
6557 - VnfLcmOperationOccurrenceNotification
6558 - VnfIdentifierCreationNotification
6559 - VnfIdentifierDeletionNotification
6562 Match particular VNF lifecycle operation types for the notification of type VnfLcmOperationOccurrenceNotification. May be present if the "notificationTypes" attribute contains the value "VnfLcmOperationOccurrenceNotification", and shall be absent otherwise.
6566 Value | Description ------|------------ INSTANTIATE | Represents the "Instantiate VNF" LCM operation. SCALE | Represents the "Scale VNF" LCM operation. SCALE_TO_LEVEL | Represents the "Scale VNF to Level" LCM operation. CHANGE_FLAVOUR | Represents the "Change VNF Flavour" LCM operation. TERMINATE | Represents the "Terminate VNF" LCM operation. HEAL | Represents the "Heal VNF" LCM operation. OPERATE | Represents the "Operate VNF" LCM operation. CHANGE_EXT_CONN | Represents the "Change external VNF connectivity" LCM operation. MODIFY_INFO | Represents the "Modify VNF Information" LCM operation.
6580 Match particular LCM operation state values as reported in notifications of type VnfLcmOperationOccurrenceNotification. May be present if the "notificationTypes" attribute contains the value "VnfLcmOperationOccurrenceNotification", and shall be absent otherwise.
6584 Value | Description ------|------------ STARTING | The LCM operation is starting. PROCESSING | The LCM operation is currently in execution. COMPLETED | he LCM operation has been completed successfully. FAILED_TEMP | The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED | The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK | The LCM operation is currently being rolled back. ROLLED_BACK | The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.
6596 String formatted according to IETF RFC 3986.
6600 Links to resources related to this resource.
6607 This type represents a link to a resource.
6614 URI of the referenced resource.
6620 A subscription with the same callbackURI and the same filter already exists and the policy of the VNFM is to not create redundant subscriptions. The HTTP response shall include a "Location" HTTP header that contains the resource URI of the existing subscription resource. The response body shall be empty.
6623 description: The resource URI of the created VNF instance
6628 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
6635 If the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem.
6638 If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
6641 If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code.The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
6644 description: The MIME type of the body of the response.
6650 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
6656 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
6664 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
6669 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
6673 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
6677 A human-readable explanation specific to this occurrence of the problem.
6681 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
6687 If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
6690 description: The MIME type of the body of the response.
6696 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
6702 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
6710 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
6715 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
6719 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
6723 A human-readable explanation specific to this occurrence of the problem.
6727 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
6733 If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it.
6736 description: The MIME type of the body of the response.
6742 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
6750 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
6755 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
6759 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
6763 A human-readable explanation specific to this occurrence of the problem.
6767 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
6773 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. Specifically in case of this task resource, the reason can also be that the task is not supported for the VNF LCM operation occurrence represented by the parent resource, and that the task resource consequently does not exist. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the sourceof the problem, e.g. a wrong resource URI variable.
6776 description: The MIME type of the body of the response.
6782 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
6790 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
6795 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
6799 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
6803 A human-readable explanation specific to this occurrence of the problem.
6807 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
6813 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
6816 description: The MIME type of the body of the response.
6822 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
6830 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
6835 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
6839 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
6843 A human-readable explanation specific to this occurrence of the problem.
6847 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
6853 If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted in that case.
6856 description: The MIME type of the body of the response.
6862 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
6870 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
6875 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
6879 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
6883 A human-readable explanation specific to this occurrence of the problem.
6887 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
6892 Internal Server Error
6893 If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond withthis response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
6896 description: The MIME type of the body of the response.
6902 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
6910 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
6915 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
6919 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
6923 A human-readable explanation specific to this occurrence of the problem.
6927 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
6933 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted.
6936 description: The MIME type of the body of the response.
6942 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
6950 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
6955 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
6959 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
6963 A human-readable explanation specific to this occurrence of the problem.
6967 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
6972 Query Subscription Information
6974 The GET method queries the list of active subscriptions of the functional block that invokes the method. It can be used e.g. for resynchronization after error situations.
6980 Content-Types that are acceptable for the response. Reference: IETF RFC 7231
6984 - name: Authorization
6986 The authorization token for the request. Reference: IETF RFC 7235
6994 The list of subscriptions was queried successfully. The response body shall contain the representations of all active subscriptions of the functional block that invokes the method.
6997 description: The MIME type of the body of the response.
7003 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
7009 This type represents a subscription related to notifications about VNF lifecycle changes.
7018 An identifier with the intention of being globally unique.
7022 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).
7025 vnfInstanceSubscriptionFilter:
7027 This type represents subscription filter criteria to match VNF instances.
7032 If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. The attributes "vnfdIds" and "vnfProductsFromProviders" are alternatives to reference to VNF instances that are based on certain VNFDs in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.
7036 An identifier with the intention of being globally unique.
7038 vnfProductsFromProviders:
7040 If present, match VNF instances that belong to VNF products from certain providers. The attributes "vnfdIds" and "vnfProductsFromProviders" are alternatives to reference to VNF instances that are based on certain VNFDs in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.
7049 Name of the VNF provider to match.
7053 If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.
7062 Name of the VNF product to match.
7066 If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.
7071 - vnfSoftwareVersion
7079 If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.
7087 If present, match VNF instances with an instance identifier listed in this attribute. The attributes "vnfInstanceIds" and "vnfInstanceNames" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.
7091 An identifier with the intention of being globally unique.
7095 If present, match VNF instances with a VNF Instance Name listed in this attribute. The attributes "vnfInstanceIds" and "vnfInstanceNames" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.
7101 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.
7106 - VnfLcmOperationOccurrenceNotification
7107 - VnfIdentifierCreationNotification
7108 - VnfIdentifierDeletionNotification
7111 Match particular VNF lifecycle operation types for the notification of type VnfLcmOperationOccurrenceNotification. May be present if the "notificationTypes" attribute contains the value "VnfLcmOperationOccurrenceNotification", and shall be absent otherwise.
7115 Value | Description ------|------------ INSTANTIATE | Represents the "Instantiate VNF" LCM operation. SCALE | Represents the "Scale VNF" LCM operation. SCALE_TO_LEVEL | Represents the "Scale VNF to Level" LCM operation. CHANGE_FLAVOUR | Represents the "Change VNF Flavour" LCM operation. TERMINATE | Represents the "Terminate VNF" LCM operation. HEAL | Represents the "Heal VNF" LCM operation. OPERATE | Represents the "Operate VNF" LCM operation. CHANGE_EXT_CONN | Represents the "Change external VNF connectivity" LCM operation. MODIFY_INFO | Represents the "Modify VNF Information" LCM operation.
7129 Match particular LCM operation state values as reported in notifications of type VnfLcmOperationOccurrenceNotification. May be present if the "notificationTypes" attribute contains the value "VnfLcmOperationOccurrenceNotification", and shall be absent otherwise.
7133 Value | Description ------|------------ STARTING | The LCM operation is starting. PROCESSING | The LCM operation is currently in execution. COMPLETED | he LCM operation has been completed successfully. FAILED_TEMP | The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED | The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK | The LCM operation is currently being rolled back. ROLLED_BACK | The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.
7145 String formatted according to IETF RFC 3986.
7149 Links to resources related to this resource.
7156 This type represents a link to a resource.
7163 URI of the referenced resource.
7169 Invalid attribute-based filtering parameters. The response body shall contain a ProblemDetails structure, in which the "detail" attribute should convey more information about the error.
7172 description: The MIME type of the body of the response.
7178 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
7184 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
7192 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
7197 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
7201 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
7205 A human-readable explanation specific to this occurrence of the problem.
7209 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
7215 If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
7218 description: The MIME type of the body of the response.
7224 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
7230 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
7238 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
7243 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
7247 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
7251 A human-readable explanation specific to this occurrence of the problem.
7255 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
7261 If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it.
7264 description: The MIME type of the body of the response.
7270 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
7278 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
7283 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
7287 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
7291 A human-readable explanation specific to this occurrence of the problem.
7295 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
7301 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. Specifically in case of this task resource, the reason can also be that the task is not supported for the VNF LCM operation occurrence represented by the parent resource, and that the task resource consequently does not exist. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the sourceof the problem, e.g. a wrong resource URI variable.
7304 description: The MIME type of the body of the response.
7310 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
7318 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
7323 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
7327 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
7331 A human-readable explanation specific to this occurrence of the problem.
7335 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
7341 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
7344 description: The MIME type of the body of the response.
7350 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
7358 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
7363 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
7367 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
7371 A human-readable explanation specific to this occurrence of the problem.
7375 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
7381 If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted in that case.
7384 description: The MIME type of the body of the response.
7390 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
7398 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
7403 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
7407 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
7411 A human-readable explanation specific to this occurrence of the problem.
7415 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
7420 Internal Server Error
7421 If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond withthis response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
7424 description: The MIME type of the body of the response.
7430 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
7438 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
7443 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
7447 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
7451 A human-readable explanation specific to this occurrence of the problem.
7455 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
7461 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted.
7464 description: The MIME type of the body of the response.
7470 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
7478 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
7483 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
7487 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
7491 A human-readable explanation specific to this occurrence of the problem.
7495 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
7498 '/subscriptions/{subscriptionId}':
7500 - name: subscriptionId
7502 Identifier of this subscription. This identifier can be retrieved from the resource referenced by the "Location" HTTP header in the response to a POST request creating a new subscription resource. It can also be retrieved from the "id" attribute in the payload body of that response.
7508 Query Subscription Information
7510 The GET method retrieves information about a subscription by reading an individual subscription resource.
7516 Content-Types that are acceptable for the response. Reference: IETF RFC 7231
7520 - name: Authorization
7522 The authorization token for the request. Reference: IETF RFC 7235
7530 The operation has completed successfully. The response body shall contain a representation of the subscription resource.
7533 description: The MIME type of the body of the response.
7539 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
7545 This type represents a subscription related to notifications about VNF lifecycle changes.
7554 An identifier with the intention of being globally unique.
7558 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).
7561 vnfInstanceSubscriptionFilter:
7563 This type represents subscription filter criteria to match VNF instances.
7568 If present, match VNF instances that were created based on a VNFD identified by one of the vnfdId values listed in this attribute. The attributes "vnfdIds" and "vnfProductsFromProviders" are alternatives to reference to VNF instances that are based on certain VNFDs in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.
7572 An identifier with the intention of being globally unique.
7574 vnfProductsFromProviders:
7576 If present, match VNF instances that belong to VNF products from certain providers. The attributes "vnfdIds" and "vnfProductsFromProviders" are alternatives to reference to VNF instances that are based on certain VNFDs in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.
7585 Name of the VNF provider to match.
7589 If present, match VNF instances that belong to VNF products with certain product names, from one particular provider.
7598 Name of the VNF product to match.
7602 If present, match VNF instances that belong to VNF products with certain versions and a certain product name, from one particular provider.
7607 - vnfSoftwareVersion
7615 If present, match VNF instances that belong to VNF products with certain VNFD versions, a certain software version and a certain product name, from one particular provider.
7623 If present, match VNF instances with an instance identifier listed in this attribute. The attributes "vnfInstanceIds" and "vnfInstanceNames" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.
7627 An identifier with the intention of being globally unique.
7631 If present, match VNF instances with a VNF Instance Name listed in this attribute. The attributes "vnfInstanceIds" and "vnfInstanceNames" are alternatives to reference to particular VNF Instances in a filter. They should not be used both in the same filter instance, but one alternative should be chosen.
7637 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.
7642 - VnfLcmOperationOccurrenceNotification
7643 - VnfIdentifierCreationNotification
7644 - VnfIdentifierDeletionNotification
7647 Match particular VNF lifecycle operation types for the notification of type VnfLcmOperationOccurrenceNotification. May be present if the "notificationTypes" attribute contains the value "VnfLcmOperationOccurrenceNotification", and shall be absent otherwise.
7651 Value | Description ------|------------ INSTANTIATE | Represents the "Instantiate VNF" LCM operation. SCALE | Represents the "Scale VNF" LCM operation. SCALE_TO_LEVEL | Represents the "Scale VNF to Level" LCM operation. CHANGE_FLAVOUR | Represents the "Change VNF Flavour" LCM operation. TERMINATE | Represents the "Terminate VNF" LCM operation. HEAL | Represents the "Heal VNF" LCM operation. OPERATE | Represents the "Operate VNF" LCM operation. CHANGE_EXT_CONN | Represents the "Change external VNF connectivity" LCM operation. MODIFY_INFO | Represents the "Modify VNF Information" LCM operation.
7665 Match particular LCM operation state values as reported in notifications of type VnfLcmOperationOccurrenceNotification. May be present if the "notificationTypes" attribute contains the value "VnfLcmOperationOccurrenceNotification", and shall be absent otherwise.
7669 Value | Description ------|------------ STARTING | The LCM operation is starting. PROCESSING | The LCM operation is currently in execution. COMPLETED | he LCM operation has been completed successfully. FAILED_TEMP | The LCM operation has failed and execution has stopped, but the execution of the operation is not considered to be closed. FAILED | The LCM operation has failed and it cannot be retried or rolled back, as it is determined that such action won't succeed. ROLLING_BACK | The LCM operation is currently being rolled back. ROLLED_BACK | The LCM operation has been successfully rolled back, i.e. The state of the VNF prior to the original operation invocation has been restored as closely as possible.
7681 String formatted according to IETF RFC 3986.
7685 Links to resources related to this resource.
7692 This type represents a link to a resource.
7699 URI of the referenced resource.
7705 If the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem.
7708 If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
7711 If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code.The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
7714 description: The MIME type of the body of the response.
7720 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
7726 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
7734 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
7739 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
7743 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
7747 A human-readable explanation specific to this occurrence of the problem.
7751 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
7757 If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
7760 description: The MIME type of the body of the response.
7766 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
7772 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
7780 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
7785 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
7789 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
7793 A human-readable explanation specific to this occurrence of the problem.
7797 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
7803 If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it.
7806 description: The MIME type of the body of the response.
7812 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
7820 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
7825 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
7829 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
7833 A human-readable explanation specific to this occurrence of the problem.
7837 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
7843 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. Specifically in case of this task resource, the reason can also be that the task is not supported for the VNF LCM operation occurrence represented by the parent resource, and that the task resource consequently does not exist. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the sourceof the problem, e.g. a wrong resource URI variable.
7846 description: The MIME type of the body of the response.
7852 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
7860 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
7865 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
7869 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
7873 A human-readable explanation specific to this occurrence of the problem.
7877 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
7883 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
7886 description: The MIME type of the body of the response.
7892 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
7900 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
7905 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
7909 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
7913 A human-readable explanation specific to this occurrence of the problem.
7917 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
7923 If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted in that case.
7926 description: The MIME type of the body of the response.
7932 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
7940 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
7945 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
7949 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
7953 A human-readable explanation specific to this occurrence of the problem.
7957 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
7962 Internal Server Error
7963 If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond withthis response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
7966 description: The MIME type of the body of the response.
7972 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
7980 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
7985 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
7989 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
7993 A human-readable explanation specific to this occurrence of the problem.
7997 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
8003 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted.
8006 description: The MIME type of the body of the response.
8012 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
8020 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
8025 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
8029 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
8033 A human-readable explanation specific to this occurrence of the problem.
8037 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
8042 Terminate Subscription
8044 The DELETE method terminates an individual subscription.
8048 - name: Authorization
8050 The authorization token for the request. Reference: IETF RFC 7235
8058 The subscription resource was deleted successfully. The response body shall be empty.
8062 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
8069 If the request is malformed or syntactically incorrect (e.g. if the request URI contains incorrect query parameters or a syntactically incorrect payload body), the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided, and should include in the "detail" attribute more information about the source of the problem.
8072 If the request contains a malformed access token, the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
8075 If there is an application error related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond with this response code.The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
8078 description: The MIME type of the body of the response.
8084 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
8090 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
8098 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
8103 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
8107 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
8111 A human-readable explanation specific to this occurrence of the problem.
8115 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
8121 If the request contains no access token even though one is required, or if the request contains an authorization token that is invalid (e.g. expired or revoked), the API producer should respond with this response. The details of the error shall be returned in the WWW-Authenticate HTTP header, as defined in IETF RFC 6750 and IETF RFC 7235. The ProblemDetails structure may be provided.
8124 description: The MIME type of the body of the response.
8130 Challenge if the corresponding HTTP request has not provided authorization, or error details if the corresponding HTTP request has provided an invalid authorization token.
8136 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
8144 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
8149 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
8153 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
8157 A human-readable explanation specific to this occurrence of the problem.
8161 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
8167 If the API consumer is not allowed to perform a particular request to a particular resource, the API producer shall respond with this response code. The "ProblemDetails" structure shall be provided. It should include in the "detail" attribute information about the source of the problem, and may indicate how to solve it.
8170 description: The MIME type of the body of the response.
8176 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
8184 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
8189 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
8193 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
8197 A human-readable explanation specific to this occurrence of the problem.
8201 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
8207 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. Specifically in case of this task resource, the reason can also be that the task is not supported for the VNF LCM operation occurrence represented by the parent resource, and that the task resource consequently does not exist. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the sourceof the problem, e.g. a wrong resource URI variable.
8210 description: The MIME type of the body of the response.
8216 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
8224 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
8229 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
8233 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
8237 A human-readable explanation specific to this occurrence of the problem.
8241 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
8247 If the API producer did not find a current representation for the resource addressed by the URI passed in the request, or is not willing to disclose that one exists, it shall respond with this response code. The "ProblemDetails" structure may be provided, including in the "detail" attribute information about the source of the problem, e.g. a wrong resource URI variable.
8250 description: The MIME type of the body of the response.
8256 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
8264 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
8269 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
8273 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
8277 A human-readable explanation specific to this occurrence of the problem.
8281 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
8287 If the "Accept" HTTP header does not contain at least one name of a content type that is acceptable to the API producer, the API producer shall respond with this response code. The "ProblemDetails" structure may be omitted in that case.
8290 description: The MIME type of the body of the response.
8296 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
8304 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
8309 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
8313 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
8317 A human-readable explanation specific to this occurrence of the problem.
8321 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
8326 Internal Server Error
8327 If there is an application error not related to the client's input that cannot be easily mapped to any other HTTP response code ("catch all error"), the API producer shall respond withthis response code. The "ProblemDetails" structure shall be provided, and shall include in the "detail" attribute more information about the source of the problem.
8330 description: The MIME type of the body of the response.
8336 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
8344 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
8349 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
8353 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
8357 A human-readable explanation specific to this occurrence of the problem.
8361 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
8367 If the API producer encounters an internal overload situation of itself or of a system it relies on, it should respond with this response code, following the provisions in IETF RFC 7231 [13] for the use of the "Retry-After" HTTP header and for the alternative to refuse the connection. The "ProblemDetails" structure may be omitted.
8370 description: The MIME type of the body of the response.
8376 The definition of the general "ProblemDetails" data structure from IETF RFC 7807 [19] is reproduced inthis structure. Compared to the general framework defined in IETF RFC 7807 [19], the "status" and "detail" attributes are mandated to be included by the present document, to ensure that the response contains additional textual information about an error. IETF RFC 7807 [19] foresees extensibility of the "ProblemDetails" type. It is possible that particular APIs in the present document, or particular implementations, define extensions to define additional attributes that provide more information about the error. The description column only provides some explanation of the meaning to Facilitate understanding of the design. For a full description, see IETF RFC 7807 [19].
8384 A URI reference according to IETF RFC 3986 [5] that identifies the problem type. It is encouraged that the URI provides human-readable documentation for the problem (e.g. using HTML) when dereferenced. When this member is not present, its value is assumed to be "about:blank".
8389 A short, human-readable summary of the problem type. It should not change from occurrence to occurrence of the problem, except for purposes of localization. If type is given and other than "about:blank", this attribute shall also be provided. A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using proactive content negotiation; see [RFC7231], Section 3.4).
8393 The HTTP status code for this occurrence of the problem. The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.
8397 A human-readable explanation specific to this occurrence of the problem.
8401 A URI reference that identifies the specific occurrence of the problem. It may yield further information if dereferenced.
Code Review / integration / csit.git / blob