Skip to content
GitLab
Commits (2)
Hide whitespace changes
Inline Side-by-side
src/SOL005/NSFaultManagement/NSFaultManagement.yaml
View file @ 8624019b
......@@ -184,16 +184,8 @@ paths:
post:
summary: Subscribe to alarms related to NSs.
description: |
The POST method creates a new subscription. This method shall follow the provisions specified in the Tables
8.4.4.3.1-1 and 8.4.4.3.1-2 for URI query parameters, request and response data structures, and response codes.
As the result of successfully executing this method, a new "Individual subscription" resource shall exist as
defined in clause 8.4.5. This method shall not trigger any notification. 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 OSS, and might make sense only in very rare use cases. Consequently, the NFVO 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).
The POST method creates a new subscription.
See clause 8.4.4.3.1.
parameters:
- $ref: ../components/SOL005_params.yaml#/components/parameters/Accept
- $ref: ../components/SOL005_params.yaml#/components/parameters/ContentType
......
src/SOL005/NSFaultManagementNotification/definitions/SOL005NSFaultManagementNotification_def.yaml
View file @ 8624019b
......@@ -119,7 +119,8 @@ definitions:
description: >
This type represents a notification that the alarm list has been rebuilt, e.g. if the NFVO detects its storage holding the
alarm list is corrupted. It shall comply with the provisions defined in Table 8.5.2.7-1.
The notification shall be triggered by the NFVO when the alarm list has been rebuilt.
The notification shall be triggered by the NFVO when the alarm list has been rebuilt, e.g. because the NFVO has detected
that its storage holding the alarm list was corrupted.
type: object
required:
- id
......
src/SOL005/NSLifecycleManagement/definitions/SOL005NSLifecycleManagement_def.yaml
View file @ 8624019b
......@@ -380,10 +380,30 @@ definitions:
VnfInstance:
description: >
This type represents a VNF instance.
Clause B.3.2 of ETSI GS NFV-SOL 003 [4] provides examples illustrating the relationship among the
different run-time information elements (CP, VL and link ports) used to represent the connectivity of a
VNF.
This type represents a VNF instance. It shall comply with the provisions defined in table 6.5.3.57-1.
NOTE: Clause B.3.2 of ETSI GS NFV-SOL 003 provides examples illustrating the relationship among the
different run-time information elements (CP, VL and link ports) used to represent the connectivity
of a VNF.
NOTE 1: Modifying the value of this attribute shall not be performed when conflicts exist between the
previous and the newly referred VNF package, i.e. when the new VNFD is changed with respect to
the previous VNFD in other aspects than merely referencing to other VNF software images.
In order to avoid misalignment of the VnfInstance with the current VNF's on-boarded VNF Package,
the values of attributes in the VnfInstance that have corresponding attributes in the VNFD shall
be kept in sync with the values in the VNFD.
NOTE 2: ETSI GS NFV-SOL 001 specifies the structure and format of the VNFD based on TOSCA specifications.
NOTE 3: VNF configurable properties are sometimes also referred to as configuration parameters applicable
to a VNF. Some of these are set prior to instantiation and cannot be modified if the VNF is instantiated,
some are set prior to instantiation (are part of initial configuration) and can be modified later,
and others can be set only after instantiation. The applicability of certain configuration may depend
on the VNF and the required operation of the VNF at a certain point in time.
NOTE 4: It is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a
multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same
VNF internal VL shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed
multi-site VL instance (refer to clause 6.5.3.59).
NOTE 5: Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall not
be listed in the "vnfVirtualLinkResourceInfo" attribute as this would be redundant.
type: object
required:
- id
......@@ -412,7 +432,8 @@ definitions:
vnfdId:
description: >
Identifier of the VNFD on which the VNF instance is based.
Modifications to this attribute can be requested using the "ModifyVnfInfoData" structure.
Modifications to this attribute can be requested using the "ModifyVnfInfoData" structure.
See note 1.
$ref: "../../definitions/SOL005_def.yaml#/definitions/Identifier"
vnfProvider:
description: >
......@@ -438,41 +459,29 @@ definitions:
$ref: "../../definitions/SOL005_def.yaml#/definitions/Identifier"
vnfConfigurableProperties:
description: >
Additional VNF-specific attributes that provide the current values
of the configurable properties of the VNF instance.
These attributes represent values that are stored persistently in the
VnfInstance structure and that correspond to configuration parameters
of the VNF instance.
Modifying these attributes affects the configuration of the VNF instance
either directly(if the VNF instance is in INSTANTIATED state at the time
of the modification) or as part of the subsequent VNF instantiation operation
(if the VNF instance is in NOT_INSTANTIATED state at the time of the modification).
Configurable properties referred in these attributes are declared in
the VNFD.
ETSI GS NFV-SOL 001 specifies the structure and format of the VNFD
based on TOSCA specifications.
VNF configurable properties are sometimes also referred to as
configuration parameters applicable to a VNF. Some of these are set
prior to instantiation and cannot be modified if the VNF is
instantiated, some are set prior to instantiation (are part of
initial configuration) and can be modified later, and others can be
set only after instantiation. The applicability of certain
configuration may depend on the VNF and the required operation of
the VNF at a certain point in time.
These configurable properties include the following standard
attributes, which are declared in the VNFD if auto-scaling and/or
auto-healing are supported by the VNF:
- isAutoscaleEnabled: If present, the VNF supports auto-scaling. If
set to true, auto-scaling is currently enabled. If set to false,
auto-scaling is currently disabled.
- isAutohealEnabled: If present, the VNF supports auto-healing. If
set to true, auto-healing is currently enabled. If set to false,
auto-healing is currently disabled.
Modifications to this attribute can be requested using the "ModifyVnfInfoData" structure.
Additional VNF-specific attributes that provide the current values of the
configurable properties of the VNF instance.
These attributes represent values that are stored persistently in the VnfInstance
structure and that correspond to configuration parameters of the VNF instance.
Modifying these attributes affects the configuration of the VNF instance either
directly (if the VNF instance is in INSTANTIATED state at the time of the modification)
or as part of the subsequent VNF instantiation operation (if the VNF instance is in
NOT_INSTANTIATED state at the time of the modification).
Configurable properties referred in these attributes are declared in the VNFD
(see note 2 and note 3).
These configurable properties include the following standard attributes, which are
eclared in the VNFD if auto-scaling and/or auto-healing are supported by the VNF:
- isAutoscaleEnabled: If present, the VNF supports auto-scaling. If set to true,
auto-scaling is currently enabled. If set to false, auto-scaling is currently
disabled.
- isAutohealEnabled: If present, the VNF supports auto-healing. If set to true,
auto-healing is currently enabled. If set to false, auto-healing is currently
disabled.
Modifications to these attributes can be requested using the "ModifyVnfInfoData" structure.
$ref: "../../definitions/SOL005_def.yaml#/definitions/KeyValuePairs"
vimId:
description: >
......@@ -481,6 +490,10 @@ definitions:
instantiationState:
description: >
The instantiation state of the VNF.
Permitted values:
- NOT_INSTANTIATED: The VNF instance is terminated or not instantiated.
- INSTANTIATED: The VNF instance is instantiated.
type: string
enum:
- NOT_INSTANTIATED
......@@ -501,7 +514,7 @@ definitions:
$ref: "../../definitions/SOL005_def.yaml#/definitions/IdentifierInVnfd"
vnfState:
description: >
The state of the VNF instance.
State of the VNF instance.
$ref: "#/definitions/VnfOperationalStateType"
scaleStatus:
description: >
......@@ -547,13 +560,8 @@ definitions:
$ref: "#/definitions/ExtVirtualLinkInfo"
extManagedVirtualLinkInfo:
description: >
External virtual links the VNF instance is connected to.
It is possible to have several ExtManagedVirtualLinkInfo for the same VNF internal VL in case of a multi-site
VNF spanning several VIMs. The set of ExtManagedVirtualLinkInfo corresponding to the same VNF internal VL
shall indicate so by referencing to the same VnfVirtualLinkDesc and externally-managed multi-site VL instance
(refer to clause 6.5.3.59).
Even though externally-managed internal VLs are also used for VNF-internal connectivity, they shall not be
listed in the "vnfVirtualLinkResourceInfo" attribute as this would be redundant.
Information about the externally-managed internal VLs of the VNF instance.
See note 4 and note 5.
type: array
items:
$ref: "#/definitions/ExtManagedVirtualLinkInfo"
......@@ -580,10 +588,11 @@ definitions:
type: array
items:
$ref: "#/definitions/VnfcResourceInfo"
virtualLinkResourceInfo:
vnfVirtualLinkResourceInfo:
description: >
Information about the virtualised network resources used by the VLs
of the VNF instance.
See note 5.
type: array
items:
$ref: "#/definitions/VnfVirtualLinkResourceInfo"
......@@ -607,7 +616,7 @@ definitions:
effect on the VNF instance, it only affects the
information represented in the VnfInstance
structure.
Metadata that the VNF provider foresees are expected to be declared in the VNFD.
Metadata that the VNF provider foresees are expected to be declared in the VNFD (see note 2).
Modifications to these attributes can be requested using the "ModifyVnfInfoData" structure.
$ref: "../../definitions/SOL005_def.yaml#/definitions/KeyValuePairs"
extensions:
......@@ -4088,7 +4097,7 @@ definitions:
to a given level, or to scale a VNF instance by steps.
type: object
required:
- vnfInstanceid
- vnfInstanceId
- scaleVnfType
oneOf:
- required:
......@@ -4941,8 +4950,6 @@ definitions:
* At least one of the "linkPortId" and "cpProtocolData" attributes
shall be present for a to-be-created external CP instance or an
existing external CP instance.
* If the "linkPortId" attribute is absent, the VNFM shall create a
link port.
* If the "cpProtocolData" attribute is absent, the "linkPortId"
attribute shall be provided referencing a pre-created link port,
and the VNFM can use means outside the scope of the present
......@@ -4952,19 +4959,14 @@ definitions:
consumer shall ensure that the cpProtocolData can be used with the
pre-created link port referenced by "linkPortId".
$ref: "../../definitions/SOL005_def.yaml#/definitions/Identifier"
createExtLinkPort:
description: >
Indicates the need to create a dedicated link port for the external CP.
If set to True, a link port is created. If set to False, no link port is created.
This attribute is only applicable for external CP instances without a floating IP
address that expose a VIP CP instance for which a dedicated IP address is allocated.
It shall be present in that case and shall be absent otherwise.
type: boolean
cpProtocolData:
description: >
Parameters for configuring the network protocols on the link port
......@@ -4973,8 +4975,6 @@ definitions:
* At least one of the "linkPortId" and "cpProtocolData" attributes
shall be present for a to-be-created external CP instance or an
existing external CP instance.
* If the "linkPortId" attribute is absent, the VNFM shall create a
link port.
* If the "cpProtocolData" attribute is absent, the "linkPortId"
attribute shall be provided referencing a pre-created link port,
and the VNFM can use means outside the scope of the present
......
src/SOL005/VNFPackageManagement/VNFPackageManagement.yaml
View file @ 8624019b
......@@ -406,15 +406,8 @@ paths:
put:
summary: Upload a VNF package by providing the content of the VNF package.
description: |
The PUT method uploads the content of a VNF package. This method shall follow the provisions specified in the
Tables 9.4.5.3.3-1 and 9.4.5.3.3-2 for URI query parameters, request and response data structures, and response
codes. Upon start of the upload of the package, the NFVO shall set the "onboardingState" attribute in the "VnfPkgInfo"
structure to "UPLOADING". Upon successful upload of the package, if the package references external artifacts, the
NFVO shall obtain the external artifacts. Subsequently, upon success, the NFVO shall set that attribute to "PROCESSING"
and shall process the package, which shall include checking package consistency. Upon successful processing, the NFVO
shall set the "onboardingState" attribute to "ONBOARDED". If an error occurs during uploading the package, downloading
the external artifacts or processing the package, the NFVO shall set the "onboardingState" attribute to "ERROR" and
shall populate the "onboardingFailureDetails" attribute in "VnfPkgInfo".
The PUT method uploads the content of a VNF package.
See clause 9.4.5.3.3.
parameters:
- $ref: ../components/SOL005_params.yaml#/components/parameters/Accept
- $ref: ../components/SOL005_params.yaml#/components/parameters/ContentType
......@@ -458,7 +451,9 @@ paths:
inclusion/exclusion defined below, embedded in a directory structure being the same as in the VNF package.
The criteria for exclusion/inclusion of an artifact in the archive are defined as follows:
* Artifacts that are software images shall be excluded from the archive.
* Artifacts that are external to the VNF package shall be excluded from the archive.
* Artifacts that are not software images and that are external to the VNF package shall be excluded from the
archive unless the URI query parameter "include_external_artifacts" has been provided. External artifacts
shall be included in the archive using the content of the "artifactPath" attribute as the path.
* All additional artifacts included in the VNF package that are MANO artifacts shall be included in the archive,
unless the URI query parameter "exclude_all_mano_artifacts" has been provided, in which case such artifacts
shall be excluded.
......@@ -516,18 +511,8 @@ paths:
summary: Upload a VNF package by providing the address information of the VNF
package.
description: |
The POST method provides the information for the NFVO to get the content of a VNF package. This method shall
follow the provisions specified in the Tables 9.4.6.3.1-1 and 9.4.6.3.1-2 for URI query parameters, request
and response data structures, and response codes. Upon start of obtaining the package, the NFVO shall set the
"onboardingState" attribute in the "VnfPkgInfo" structure to "UPLOADING". Upon successfully obtaining the
package, if the package references external artifacts, the NFVO shall obtain the external artifacts. Subsequently,
upon success, the NFVO shall set that attribute to "PROCESSING" and shall process the package, which shall include
checking package consistency. Upon successful processing, the NFVO shall set the "onboardingState" attribute to
"ONBOARDED", the "operationalState" attribute to "ENABLED", and the "usageState" attribute to "NOT_IN_USE".
In addition, the NFVO shall set the value of the attributes in the "VnfPkgInfo" that are copied from the VNFD
(refer to clause 9.5.2.5). If an error occurs during obtaining the package, downloading the external artifacts or processing
the package, the NFVO shall set the "onboardingState" attribute to "ERROR" and shall populate the "onboardingFailureDetails"
attribute in "VnfPkgInfo".
The POST method provides the information for the NFVO to get the content of a VNF package.
See clause 9.4.6.3.1.
parameters:
- $ref: ../components/SOL005_params.yaml#/components/parameters/ContentType
requestBody:
......@@ -567,9 +552,8 @@ paths:
get:
summary: Fetch individual VNF package artifact.
description: |
The GET method fetches the content of an artifact within a VNF package. This method shall follow the provisions
specified in the Tables 9.4.7.3.2-1 and 9.4.7.3.2-2 for URI query parameters, request and response data structures,
and response codes.
The GET method fetches the content of an artifact within a VNF package.
See clause 9.4.7.3.2.
parameters:
- $ref: ../components/SOL005_params.yaml#/components/parameters/Accept
- $ref: ../components/SOL005_params.yaml#/components/parameters/Range
......
src/SOL005/VNFPackageManagement/definitions/SOL005VNFPackageManagement_def.yaml
View file @ 8624019b
......@@ -201,6 +201,18 @@ definitions:
description: >
Checksum of the artifact file. Permitted hash algorithms are defined in ETSI GS NFV-SOL 004.
$ref: "../../definitions/SOL005_def.yaml#/definitions/Checksum"
isEncrypted:
description: >
Reflects whether the artifact is encrypted (true) or not (false).
type: boolean
nonManoArtifactSetId:
description: >
Non-MANO artifact set identifier of the non-MANO artifact
set to which the artifact belongs, as defined in
clause 4.3.7 of ETSI GS NFV-SOL 004 [5]. Shall be
provided if the artifact is a non-MANO artifact, and shall
be omitted otherwise.
type: string
artifactClassification:
description: >
Marks specific types of artifacts as defined in the VNF
......@@ -208,28 +220,16 @@ definitions:
applies, the attribute shall not be present.
Valid values:
- HISTORY: a history artifact as per clause 4.3.3
in ETSI GS NFV-SOL 004 [5]
in ETSI GS NFV-SOL 004
- TESTING: a testing artifact as per clause 4.3.4
in ETSI GS NFV-SOL 004 [5]
in ETSI GS NFV-SOL 004
- LICENSE: a license artifact as per clause 4.3.5
in ETSI GS NFV-SOL 004 [5]
in ETSI GS NFV-SOL 004
type: string
enum:
- HISTORY
- TESTING
- LICENSE
isEncrypted:
description: >
Reflects whether the artifact is encrypted (true) or not (false).
type: boolean
nonManoArtifactSetId:
description: >
Non-MANO artifact set identifier of the non-MANO artifact
set to which the artifact belongs, as defined in
clause 4.3.7 of ETSI GS NFV-SOL 004 [5]. Shall be
provided if the artifact is a non-MANO artifact, and shall
be omitted otherwise.
type: string
metadata:
description: >
The metadata of the artifact that are available in the
......
src/SOL005/components/SOL005_params.yaml
View file @ 8624019b
......@@ -159,7 +159,7 @@ components:
in: query
description: |
Flag (i.e. parameter without value) that instructs the NFVO to exclude the set of non-MANO artifacts from the
response payload body. The NFVO shall support this parameter. The VNFM may supply this parameter.
response payload body. The NFVO shall support this parameter. The OSS/BSS may supply this parameter.
required: false
style: form
explode: true
......@@ -172,7 +172,7 @@ components:
description: |
Comma-separated list of non-MANO artifact set identifiers for which the artifacts are to be included in the
response body. The NFVO should support this parameter. If the NFVO does not support this parameter, it shall
ignore it, i.e. provide a response as if no parameter was provided. The VNFM may supply this parameter.
ignore it, i.e. provide a response as if no parameter was provided. The OSS/BSS may supply this parameter.
required: false
style: form
explode: true
......