From 34421873242766c036dcee84056b204329fabaa5 Mon Sep 17 00:00:00 2001
From: piscione <ubuntu@ubuntu1604.linuxvmimages.com>
Date: Fri, 7 May 2021 10:59:25 +0200
Subject: [PATCH] SOL005_61 to SOL005_70
---
.../SOL005NSLifecycleManagement_def.yaml | 248 +++++++++---------
1 file changed, 121 insertions(+), 127 deletions(-)
diff --git a/src/SOL005/NSLifecycleManagement/definitions/SOL005NSLifecycleManagement_def.yaml b/src/SOL005/NSLifecycleManagement/definitions/SOL005NSLifecycleManagement_def.yaml
index 2064c0b..26ebc8a 100644
--- a/src/SOL005/NSLifecycleManagement/definitions/SOL005NSLifecycleManagement_def.yaml
+++ b/src/SOL005/NSLifecycleManagement/definitions/SOL005NSLifecycleManagement_def.yaml
@@ -1250,7 +1250,15 @@ definitions:
IpOverEthernetAddressInfo:
description: >
This type represents information about a network address that has been assigned.
- It shall comply with the provisions defined in Table 6.5.3.18-1.
+
+ NOTE 1: At least one of "macAddress" or "ipAddresses" shall be present.
+ NOTE 2: Exactly one of "addresses" or "addressRange" shall be present.
+ NOTE 3: If the Cp instance represents a subport in a trunk, "segmentationId" shall be present. Otherwise it shall not be present.
+ NOTE 4: Depending on the NFVI networking infrastructure, the "segmentationId" may indicate the actual network segment value
+ (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header of the packets or it may be an identifier
+ used between the application and the NFVI networking infrastructure to identify the network sub-interface
+ of the trunk port in question. In the latter case the NFVI infrastructure will map this local
+ "segmentationId" to whatever "segmentationId" is actually used by the NFVI's transport technology.
type: object
anyOf:
- required:
@@ -1261,23 +1269,20 @@ definitions:
macAddress:
description: >
Assigned MAC address.
+
+ See note 1.
$ref: "#/definitions/MacAddress"
segmentationId:
description: >
Identification of the network segment to which the Cp instance connects to.
- If the Cp instance represents a subport in a trunk, "segmentationId" shall be present.
- Otherwise it shall not be present.
- Depending on the NFVI networking infrastructure, the "segmentationId" may indicate the actual network segment
- value (e.g. vlan Id, Vxlan segmentation id, etc.) used in the transport header of the packets or it may be an
- identifier used between the application and the NFVI networking infrastructure to identify the network sub-interface
- of the trunk port in question. In the latter case the NFVI infrastructure will map this local "segmentationId"
- to whatever "segmentationId" is actually used by the NFVI’s transport technology.
+ See note 3 and note 4.
type: string
ipAddresses:
description: >
Addresses assigned to the CP instance. Each entry represents IP
addresses assigned by fixed or dynamic IP address assignment per
subnet.
+ See note 1.
type: array
items:
type: object
@@ -1303,6 +1308,7 @@ definitions:
description: >
Fixed addresses assigned (from the subnet defined by
"subnetId" if provided).
+ See note 2.
type: array
items:
$ref: "#/definitions/IpAddress"
@@ -1317,6 +1323,7 @@ definitions:
description: >
An IP address range used, e.g., in case of egress connections.
Exactly one of "addresses" or "addressRange" shall be present.
+ See note 2.
type: object
required:
- minAddress
@@ -2110,17 +2117,20 @@ definitions:
• as a country code
• as a civic address combined with a country code
• as an area, conditionally combined with a country code
- The LocationConstraints data type shall comply with the provisions defined in Table 6.5.3.21-1.
+
+ NOTE: If both "countryCode" and "area" are present, no conflicts should
+ exist between the values of these two attributes. In case of conflicts,
+ the API producer (i.e. the NFVO) shall disregard parts of the geographic
+ area signalled by "area" that are outside the boundaries of the country
+ signalled by "countryCode". If "countryCode" is absent, it is solely the "area"
+ attribute that defines the location constraint.
type: object
properties:
countryCode:
description: >
- The two-letter ISO 3166 [29] country code in capital letters.
- Shall be present in case the "area" attribute is absent. May be absent if the "area" attribute is present.
- If both "countryCode" and "area" are present, no conflicts should exist between the values of these two attributes.
- In case of conflicts, the API producer (i.e. the NFVO) shall disregard parts of the geographic area signalled
- by "area" that are outside the boundaries of the country signalled by "countryCode". If "countryCode" is absent,
- it is solely the "area" attribute that defines the location constraint.
+ The two-letter ISO 3166 country code in capital letters. Shall be present
+ in case the "area" attribute is absent. May be absent if the "area"
+ attribute is present (see note).
type: string
civicAddressElement:
description: >
@@ -2150,10 +2160,7 @@ definitions:
Geographic area. Shall be absent if the "civicAddressElement" attribute is present.
The content of this attribute shall follow the provisions for the "Polygon" geometry object as defined in
IETF RFC 7946, for which the "type" member shall be set to the value "Polygon".
- If both "countryCode" and "area" are present, no conflicts should exist between the values of these two attributes.
- In case of conflicts, the API producer (i.e. the NFVO) shall disregard parts of the geographic area signalled
- by "area" that are outside the boundaries of the country signalled by "countryCode". If "countryCode" is absent,
- it is solely the "area" attribute that defines the location constraint.
+ See note.
type: object
VnfLocationConstraint:
@@ -2593,8 +2600,19 @@ definitions:
This type represents the information related to a SAP of a NS. The InstantiateVnfData data type specifies the
parameters that are needed for VNF instantiation. This information element is used for the bottom-up NS creation when
the OSS/BSS explicitly requests VNF instantiation for a given NS. When the NFVO invokes the Instantiate VNF
- update operation, a set of these parameters are then passed by the NFVO to the VNFM. It shall comply with the
- provisions defined in Table 6.5.3.24-1.
+ update operation, a set of these parameters are then passed by the NFVO to the VNFM.
+
+ NOTE 1: It is possible to have several ExtManagedVirtualLinkData for the same VNF internal
+ VL in case of a multi-site VNF spanning several VIMs. The set of ExtManagedVirtualLinkData
+ 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.27).
+ NOTE 2: If vnfdId and vnfFlavourId (and vnfInstantiationLevelId, if provided) are present,
+ there should be only one vnfProfile that matches the vnfdId and vnfFlavourId (and vnfInstantiationLevelId,
+ if present) in the NS deployment flavour specified in the NSD associated to the NS instance to which
+ the present operation is triggered. In the case there is more than one matching vnfProfile, the NFVO
+ may select a matching vnfProfile based on other information, such as external VL.
+ NOTE 3: Either the attribute triple "vnfdId, vnfFlavourId and vnfInstantiationLevelId
+ (if provided)" or the attribute "vnProfileId" shall be present, but not both.
type: object
properties:
vnfdId:
@@ -2602,33 +2620,13 @@ definitions:
Information sufficient to identify the VNFD which defines
the VNF to be instantiated.
- If vnfdId and vnfFlavourId (and vnfInstantiationLevelId,
- if provided) are present, there should be only one vnfProfile
- that matches the vnfdId and vnfFlavourId (and vnfInstantiationLevelId,
- if present) in the NS deployment flavour specified in the NSD
- associated to the NS instance to which the present operation is
- triggered. In the case there is more than one matching vnfProfile,
- the NFVO may select a matching vnfProfile based on other information,
- such as external VL.
-
- Either the attribute triple "vnfdId, vnfFlavourId and vnfInstantiationLevelId
- (if provided)" or the attribute "vnProfileId" shall be present, but not both.
+ See note 2 and 3.
$ref: "../../definitions/SOL005_def.yaml#/definitions/Identifier"
vnfFlavourId:
description: >
Identifier of the VNF deployment flavor to be instantiated.
- If vnfdId and vnfFlavourId (and vnfInstantiationLevelId,
- if provided) are present, there should be only one vnfProfile
- that matches the vnfdId and vnfFlavourId (and vnfInstantiationLevelId,
- if present) in the NS deployment flavour specified in the NSD
- associated to the NS instance to which the present operation is
- triggered. In the case there is more than one matching vnfProfile,
- the NFVO may select a matching vnfProfile based on other information,
- such as external VL.
-
- Either the attribute triple "vnfdId, vnfFlavourId and vnfInstantiationLevelId
- (if provided)" or the attribute "vnProfileId" shall be present, but not both.
+ See note 2 and 3.
$ref: "../../definitions/SOL005_def.yaml#/definitions/IdentifierInVnfd"
vnfInstantiationLevelId:
description: >
@@ -2637,24 +2635,13 @@ definitions:
instantiation level as declared in the VNFD is
instantiated.
- If vnfdId and vnfFlavourId (and vnfInstantiationLevelId,
- if provided) are present, there should be only one vnfProfile
- that matches the vnfdId and vnfFlavourId (and vnfInstantiationLevelId,
- if present) in the NS deployment flavour specified in the NSD
- associated to the NS instance to which the present operation is
- triggered. In the case there is more than one matching vnfProfile,
- the NFVO may select a matching vnfProfile based on other information,
- such as external VL.
-
- Either the attribute triple "vnfdId, vnfFlavourId and vnfInstantiationLevelId
- (if provided)" or the attribute "vnProfileId" shall be present, but not both.
+ See note 2 and 3.
$ref: "../../definitions/SOL005_def.yaml#/definitions/IdentifierInVnfd"
vnfProfileId:
description: >
Identifier of (Reference to) a vnfProfile defined in the NSD which is used for instantiating the VNF.
- Either the attribute triple "vnfdId, vnfFlavourId and vnfInstantiationLevelId
- (if provided)" or the attribute "vnProfileId" shall be present, but not both.
+ See note 3.
$ref: "#/definitions/IdentifierInNsd"
vnfInstanceName:
description: >
@@ -2667,16 +2654,14 @@ definitions:
extVirtualLinks:
description: >
Information about external VLs to connect the VNF to.
+
type: array
items:
$ref: "#/definitions/ExtVirtualLinkData"
extManagedVirtualLinks:
description: >
Information about internal VLs that are managed by other entities than the VNFM.
- It is possible to have several ExtManagedVirtualLinkData for the same VNF internal VL in case of a multi-site
- VNF spanning several VIMs. The set of ExtManagedVirtualLinkData 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.27).
+ See note 1.
type: array
items:
$ref: "#/definitions/ExtManagedVirtualLinkData"
@@ -2693,7 +2678,7 @@ definitions:
It provides values for the "vnfConfigurableProperties" input
parameter of the Instantiate VNF operation
- defined in ETSI GS NFV-SOL 003 [4].
+ defined in ETSI GS NFV-SOL 003.
$ref: "../../definitions/SOL005_def.yaml#/definitions/KeyValuePairs"
additionalParams:
description: >
@@ -2730,7 +2715,17 @@ definitions:
description: >
The type represents the information that is requested to be changed
deployment flavor for an existing VNF instance.
- It shall comply with the provisions defined in Table 6.5.3.25-1.
+ NOTE 1: The indication of externally-managed internal VLs
+ is needed in case networks have been pre-configured for use with certain VNFs,
+ for instance to ensure that these networks have certain properties such as
+ security or acceleration features, or to address particular network topologies.
+ The present document assumes that externally-managed internal VLs are managed
+ by the NFVO and created towards the VIM.
+ NOTE 2: It is possible to have several ExtManagedVirtualLinkData for the same
+ VNF internal VL in case of a multi-site VNF spanning several VIMs. The set
+ of ExtManagedVirtualLinkData 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.27).
type: object
required:
- vnfInstanceId
@@ -2760,14 +2755,7 @@ definitions:
extManagedVirtualLinks:
description: >
information about internal VLs that are managed by NFVO.
- The indication of externally-managed internal VLs is needed in case networks have been pre-configured for use
- with certain VNFs, for instance to ensure that these networks have certain properties such as security or
- acceleration features, or to address particular network topologies. The present document assumes that
- xternally-managed internal VLs are managed by the NFVO and created towards the VIM.
- It is possible to have several ExtManagedVirtualLinkData for the same VNF internal VL in case of a multi-site
- VNF spanning several VIMs. The set of ExtManagedVirtualLinkData 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.27).
+ See note 1 and note 2.
type: array
items:
$ref: "#/definitions/ExtManagedVirtualLinkData"
@@ -2791,8 +2779,16 @@ definitions:
OperateVnfData:
description: >
This type represents a VNF instance for which the operational state
- needs to be changed and the requested new state. It
- shall comply with the provisions defined in Table 6.5.3.31-1.
+ needs to be changed and the requested new state.
+ NOTE: The "stopType" and "gracefulStopTimeout" attributes shall be absent,
+ when the "changeStateTo" attribute is equal to "STARTED". The "gracefulStopTimeout"
+ attribute shall be present, when the "changeStateTo" attribute is equal to "STOPPED"
+ and the "stopType" attribute is equal to "GRACEFUL". The "gracefulStopTimeout"
+ attribute shall be absent, when the "changeStateTo" attribute is equal to
+ "STOPPED" and the "stopType" attribute is equal to "FORCEFUL". The request
+ shall be treated as if the "stopType" attribute was set to "FORCEFUL", when
+ the "changeStateTo" attribute is equal to "STOPPED" and the "stopType" attribute
+ is absent.
type: object
required:
- vnfInstanceId
@@ -2809,13 +2805,14 @@ definitions:
$ref: "#/definitions/OperationalStates"
stopType:
description: >
- It signals whether forceful or graceful stop is requested.
+ It signals whether forceful or graceful stop is requested.
+ See note.
$ref: "#/definitions/StopType"
gracefulStopTimeout:
description: >
The time interval (in seconds) to wait for the VNF to be
taken out of service during graceful stop, before
- stopping the VNF.
+ stopping the VNF. See note.
type: integer
additionalParam:
description: >
@@ -3294,6 +3291,7 @@ definitions:
This type specifies an PNF to be modified in the NS instance.
It shall comply with the provisions defined in
Table 6.5.3.15-1.
+ NOTE: At least one attribute shall be present.
type: object
required:
- pnfId
@@ -3309,11 +3307,11 @@ definitions:
$ref: "../../definitions/SOL005_def.yaml#/definitions/Identifier"
pnfName:
description: >
- Name of the PNF.
+ Name of the PNF. See note.
type: string
cpData:
description: >
- Address assigned for the PNF external CP(s).
+ Address assigned for the PNF external CP(s). See note.
type: array
items:
$ref: "#/definitions/PnfExtCpData"
@@ -4796,7 +4794,17 @@ definitions:
ExtVirtualLinkData:
description: >
- This type represents an external VL. It shall comply with the provisions defined in Table 6.5.3.26-1.
+ This type represents an external VL.
+
+ NOTE: A link port is not needed for an external CP instance that exposes a VIP CP in the following cases:
+ 1. For a VIP CP directly exposed as extCP:
+ 1.1. no dedicated IP address is allocated as VIP address, as indicated in the VNFD
+ 1.2. a dedicated IP address is allocated as VIP address,
+ but the NFVO indicates that no port is needed (createExtLinkPort in VnfExtCpConfig set to false).
+ 2. For a VIP CP exposed as extCP via a floating IP address:
+ 2.1. no dedicated IP address is allocated as VIP address, as indicated in the VNFD,
+ and the VNFC CP associated to the VIP CP is also exposed via a floating IP address.
+
type: object
required:
- resourceId
@@ -4838,15 +4846,7 @@ definitions:
external connection points to this external VL unless
the extCp exposes a VIP CP and a link port is not needed
for it based on the conditions defined below.
-
- A link port is not needed for an external CP instance that exposes a VIP CP in the following cases:
- 1. For a VIP CP directly exposed as extCP:
- 1.1. no dedicated IP address is allocated as VIP address, as indicated in the VNFD
- 1.2. a dedicated IP address is allocated as VIP address, but the NFVO indicates that no port is needed
- (createExtLinkPort in VnfExtCpConfig set to false).
- 2. For a VIP CP exposed as extCP via a floating IP address:
- 2.1. no dedicated IP address is allocated as VIP address, as indicated in the VNFD,
- and the VNFC CP associated to the VIP CP is also exposed via a floating IP address.
+ See note.
type: array
items:
$ref: "#/definitions/ExtLinkPortData"
@@ -4909,6 +4909,21 @@ definitions:
description: >
This type represents configuration information for external CPs created
from a CPD.
+
+ NOTE 1: In case this identifier refers to a CPD with trunking enabled, the external
+ CP instances created from this CPD will represent ports in a trunk.
+ NOTE 2: The map entry value shall be set to "null" in order to delete a "VnfExtCpConfig"
+ entry identified by a particular key value from the map, i.e. for the disconnection of an
+ existing external CP instance addressed by cpInstanceId in the deleted map entry from a particular
+ external virtual link, and deletion of that instance in case it represents a subport. Deleting
+ the last key from the map removes the affected instance of the "VnfExtCpData" structure from its
+ parent data structure.
+ NOTE 3: Within one VNF instance, all VNFC instances created from a particular VDU have the
+ same external connectivity. Thus, given a particular value of the "cpdId' attribute, there
+ shall be one "cpConfig" entry for each VNFC instance that has been or can be created from
+ a VDU which includes a CPD identified by the "cpdId" attribute. If the cpConfig represents
+ a subport in a trunk, all "cpConfig" entries in this list shall have the same segmentationId,
+ which means they are connected to the same set of external VLs via the trunk.
type: object
required:
- cpdId
@@ -4916,24 +4931,14 @@ definitions:
cpdId:
description: >
The identifier of the CPD in the VNFD.
- In case this identifier refers to a CPD with trunking enabled, the external CP instances created from this CPD
- will represent ports in a trunk.
+ See note 1.
$ref: "../../definitions/SOL005_def.yaml#/definitions/IdentifierInVnfd"
cpConfig:
description: >
Map of instance data that need to be configured on the CP instances created from the respective CPD.
The key of the map which identifies the individual VnfExtCpConfig entries is managed by the API consumer.
The entries shall be applied by the VNFM according to the rules of JSON Merge Patch (see IETF RFC 7396).
- The map entry value shall be set to "null" in order to delete a "VnfExtCpConfig" entry identified by a
- particular key value from the map, i.e. for the disconnection of an existing external CP instance addressed
- by cpInstanceId in the deleted map entry from a particular external virtual link, and deletion of that
- instance in case it represents a subport. Deleting the last key from the map removes the affected instance
- of the "VnfExtCpData" structure from its parent data structure.
- Within one VNF instance, all VNFC instances created from a particular VDU have the same external connectivity.
- Thus, given a particular value of the “cpdId’ attribute, there shall be one “cpConfig†entry for each VNFC
- instance that has been or can be created from a VDU which includes a CPD identified by the “cpdId†attribute.
- If the cpConfig represents a subport in a trunk, all “cpConfig†entries in this list shall have the same
- segmentationId, which means they are connected to the same set of external VLs via the trunk.
+ See note 2 and note 3.
type: object
additionalProperties:
$ref: "#/definitions/VnfExtCpConfig"
@@ -4942,6 +4947,7 @@ definitions:
description: >
This type represents an externally provided link port to be used to
connect an external connection point to an external VL.
+ NOTE: The value of "trunkResourceId" is scoped by the value of "vimConnectionId" in the "resourceHandle" attribute.
type: object
required:
- id
@@ -4961,9 +4967,7 @@ definitions:
Identifier of the trunk resource in the VIM.
Shall be present if the present link port corresponds to the parent
port that the trunk resource is associated with.
-
- The value of "trunkResourceId" is scoped by the value of "vimConnectionId"
- in the "resourceHandle" attribute.
+ See note.
$ref: "../../definitions/SOL005_def.yaml#/definitions/IdentifierInVim"
VnfExtCpConfig:
@@ -4974,6 +4978,19 @@ definitions:
external CP to the external VL. In a link port is not provided, the VNFM
shall create a link port on the external VL, and use that link port to
connect the external CP to the external VL.
+ NOTE 1: The following conditions apply to the attributes "linkPortId" and "cpProtocolData":
+ - At least one of the "linkPortId" and "cpProtocolData" attributes shall be present for
+ an external CP instance representing a subport that is to be created, or an external CP instance
+ that is to be created by creating the corresponding VNFC or VNF instance during the current or
+ a subsequent LCM operation, or for an existing external CP instance that is to be re-configured
+ or added to a particular external virtual link.
+ - If the "cpProtocolData" attribute is absent, the "linkPortId" attribute shall be provided
+ referencing a pre-created link port with pre-configured address information.
+ - If both "cpProtocolData" and "linkportId" are provided, the API consumer shall ensure that
+ the cpProtocolData can be used with the pre-created link port referenced by "linkPortId".
+ NOTE 2: In case the NFVO manages its own identifier space, the NFVO may remap this identifier
+ when communicating with the VNFM. If the NFVO knows that there can be an identifier collision
+ when communicating with the VNFM by using the identifier from the OSS/BSS, the NFVO shall remap it.
type: object
anyOf:
- required:
@@ -4985,25 +5002,13 @@ definitions:
description: >
Value of the key that identifies to the "VnfExtCpConfig" entry that corresponds to the parent port of the trunk.
Only present in "VnfExtCpConfig" map structures which provide configuration information for a CP which represents
- a subport in a trunk, and if parent ports are supported.
+ a subport in a trunk, and if parent ports are supported. See note 2.
$ref: "#/definitions/IdentifierInVnf"
linkPortId:
description: >
Identifier of a pre-configured link port to which the external CP
will be associated.
- The following conditions apply to the attributes "linkPortId" and
- "cpProtocolData":
- * 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 "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
- document to obtain the pre-configured address information for the
- connection point from the resource representing the link port.
- * If both "cpProtocolData" and "linkportId" are provided, the API
- consumer shall ensure that the cpProtocolData can be used with the
- pre-created link port referenced by "linkPortId".
+ See note 1.
$ref: "../../definitions/SOL005_def.yaml#/definitions/Identifier"
createExtLinkPort:
description: >
@@ -5017,18 +5022,7 @@ definitions:
description: >
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":
- * 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 "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
- document to obtain the pre-configured address information for the
- connection point from the resource representing the link port.
- * If both "cpProtocolData" and "linkportId" are provided, the API
- consumer shall ensure that the cpProtocolData can be used with the
- pre-created link port referenced by "linkPortId".
+ See note 1.
type: array
items:
$ref: "#/definitions/CpProtocolData"
--
GitLab