Yasufumi Ogawa af542c4418 Remove sphinxcontrib-*diag

As suggested open openstack-discuss ML[1], some sphinxcontrib packages
have not been updated for several years and might going to be
maintained anymore. In tacker-specs repo, many diagrams are compiled
with sphinxcontrib-seqdiag and sphinxcontrib-nwdiag. This update is to
drop using the packages and add image files instead. The embedded
source codes are remained as separated files and named as "*.diag".

In addition, it includes two updates other than that.

* usage of the dropped diagram support described in the
  `specs/template.rst` is also removed because it's no longer
  supported.

* Upgrade the version of `pillow` to the latest 11.0.0 since
  installation is failed if the version is old.

[1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/4IID4UEXY4PJJGBTMFMTRYLKJIN4GOQ6/

Change-Id: I8cede6de0770b68a9984617643aa4aa81e47ba5c

2024-12-04 09:01:41 +00:00

25 KiB

Raw Blame History

Enhance NFV SOL_v3 LCM operation

This specification supports a new version of VNF lifecycle management APIs complying with ETSI NFV SOL v3. It adds a new version of APIs involved in operating instantiated VNF instances (scale, heal, modify, and change external vnf connectivity).

Problem description

ETSI specifications within the NFV Architecture Framework¹ describe the main aspects of NFV development and usage based on the industry needs, feedback from SDN/NFV vendors and telecom operators. These specifications include the REST API and data model architecture which is used by NFV users and developers in related products.

Support of key ETSI NFV specifications will significantly reduce efforts for Tacker integration into Telecom production networks and also will simplify further development and support of future standards. To integrate Tacker into a wide variety of products, it should comply with multiple versions of ETSI NFV SOL specifications. Tacker has already supported VNF lifecycle management operations defined in ETSI NFV SOL002 v2.6.1² and SOL003 v2.6.1³. Furthermore, Xena release supported a part of VNF lifecycle management operations defined in ETSI NFV SOL002 v3.3.1⁴ and SOL003 v3.3.1⁵. The details of supported APIs are described in Tacker Xena Specifications ⁶ ⁷. Tacker should support more VNF lifecycle management operations defined in ETSI NFV SOL002/003 v3.3.1.

Proposed change

Since the VNF lifecycle management interface version specified in ETSI NFV SOL v3 is "2.0.0", the API major version included in the URI shall be set to "v2". Supporting v2 APIs involves changing the data type of some attributes and adding or removing attributes. To avoid impact on the existing implementation, APIs corresponding to "v2" should be implemented as a process independent of that of "v1".

This interface supports the following APIs involved in getting information of lifecycle management operation.

Scale VNF (POST /vnf_instances/{vnfInstanceId}/scale)
Heal VNF (POST /vnf_instances/{vnfInstanceId}/heal)
Modify VNF Information (PATCH /vnf_instances/{vnfInstanceId})
Change External VNF Connectivity (POST /vnf_instances/{vnfInstanceId}/change_ext_conn)

1) Flow of Scale VNF

The procedure consists of the following steps as illustrated in above sequence:

Precondition: VNF instance in INSTANTIATED state.

Client sends VNFM a POST request for the Scale VNF Instance.
VNFM sends endpoints such as Client a VNF lifecycle management operation occurrence notification with the "STARTING" state to indicate the start occurrence of the lifecycle management operation.
VNFM and NFVO exchange granting information.
VNFM sends endpoints such as Client a VNF lifecycle management operation occurrence notification with the "PROCESSING" state to indicate the processing occurrence of the lifecycle management operation.
MgmtDriver executes preamble operation according to a MgmtDriver script.
The number of VMs to scale is calculated by multiplying "number_of_steps" contained in Scale VNF request and "number_of_instances" contained in VNFD.
Only for scale-in, OpenstackDriver sends Heat mark stack unhealthy request for the removed VM.
OpenstackDriver sends Heat stack-update request with the incremented or decremented "desired_capacity" of AutoScalingGroup for the target VM.
MgmtDriver executes postamble operation according to a MgmtDriver script.
VNFM sends endpoints such as Client a VNF lifecycle management operation occurrence notification with the "COMPLETED" state or "FAILED_TEMP" state to indicate the result of the lifecycle management operation.

Postcondition: VNF instance is still in INSTANTIATED state and VNF has been scaled.

Note

Scale API version 1 supports is_reverse option. Scale-in operation with this option deletes VNF from the last registered VM. Scale API version 2 does not support this option because it deletes VM in this order by default.

Note

Tacker does not support non-uniform deltas defined in ETSI NFV SOL001⁸. Therefore, uniform delta corresponding to "number_of_instances" can be set and "number_of_instances" is the same regardless of scale_level.

2) Flow of Heal VNF

The client can specify the target resources for healing with two parameters in the API request.

vnfcInstanceId is a list which indicates VNFC instances for which a healing action is requested.
all indicates whether network resources and storage resources are included in the heal target. This is set in the attribute of additionalParams.

With the combination of these parameters, Tacker supports the following patterns of healing.

Pattern A. vnfcInstanceId is included in the request.
- Pattern A-1. all = False is included in the request or all is not included in the request.
  
  Only specified VNFC instances are healed.
- Pattern A-2. all = True are included in the request.
  
  Specified VNFC instances and storage resources are healed.
Pattern B. vnfcInstanceId is not included in the request.
- Pattern B-1. all = False is included in the request or all is not included in the request.
  
  All VNFC instances included in the VNF instance are healed.
- Pattern B-2. all = True are included in the request.
  
  All resources included in the VNF instance are healed. It includes VNFC instances, network resources, and storage resources but not external virtual networks.

The heal operation of pattern B-2 can be implemented by combining terminate vnf and instantiate vnf.

The following shows the sequence of patterns A-1, A-2, and B-1.

The procedure consists of the following steps as illustrated in above sequence:

Precondition: VNF instance in INSTANTIATED state.

Client sends a POST request for the Heal VNF Instance.
VNFM sends endpoints such as Client a VNF lifecycle management operation occurrence notification with the "STARTING" state to indicate the start occurrence of the lifecycle management operation.
VNFM and NFVO exchange granting information.
VNFM sends endpoints such as Client a VNF lifecycle management operation occurrence notification with the "PROCESSING" state to indicate the processing occurrence of the lifecycle management operation.
MgmtDriver executes preamble operation according to a MgmtDriver script.
OpenstackDriver sends Heat mark stack unhealthy request for the target VM according to the heal request parameter.
OpenstackDriver sends Heat stack-update request to execute heal. When scaling multiple VMs, stack-update are repeated as a set for each VM.
MgmtDriver executes postamble operation according to a MgmtDriver script.
VNFM sends endpoints such as Client a VNF lifecycle management operation occurrence notification with the "COMPLETED" state or "FAILED_TEMP" state to indicate the result of the lifecycle management operation.

Postcondition: VNF instance in "INSTANTIATED" state, and healed.

3) Flow of the Modify VNF Information

Precondition: The resource representing the VNF instance has been created.

Client sends VNFM a PATCH request for the Modify VNF instance's information.
VNFM sends endpoints such as Client a VNF lifecycle management operation occurrence notification with the "PROCESSING" state to indicate the processing occurrence of the lifecycle management operation.
VNFM modifies the VNF instance's information.
VNFM sends endpoints such as Client a VNF lifecycle management operation occurrence notification with the "COMPLETED" state or "FAILED_TEMP" state to indicate the result of the lifecycle management operation.

Postcondition: After successful completion, information of the VNF instance is updated.

4) Flow of Change external VNF connectivity

The procedure consists of the following steps as illustrated in above sequence:

Precondition: VNF instance in INSTANTIATED state.

Client sends VNFM a POST request for the change external VNF connectivity.
VNFM sends endpoints such as Client a VNF lifecycle management operation occurrence notification with the "STARTING" state to indicate the start occurrence of the lifecycle management operation.
VNFM and NFVO exchange granting information.
VNFM sends endpoints such as Client a VNF lifecycle management operation occurrence notification with the "PROCESSING" state to indicate the processing occurrence of the lifecycle management operation.
MgmtDriver executes preamble operation according to a MgmtDriver script.
OpenstackDriver sends Heat stack-update request with the external Virtual Link (VL) and external Connection Point to change.
MgmtDriver executes postamble operation according to a MgmtDriver script.
VNFM sends endpoints such as Client a VNF lifecycle management operation occurrence notification with the "COMPLETED" state or "FAILED_TEMP" state to indicate the result of the lifecycle management operation.

Postcondition: VNF instance is still in INSTANTIATED state and the external VNF connectivity has been changed.

This specification supports the following VL's changes.

port
network.
ip address/mac address/allowed_address_pair in VLs.

This specification does not support trunk-parent-port and trunk-sub-port.

Data model impact

The change has no impact for data model.

Since Xena release has already supported all attributes defined in SOL002 v3.3.1⁹ and SOL003 v3.3.1¹⁰, data objects and database tables do not need to be changed.

REST API impact

All defined attributes should be supported in API validation.

Name: Scale a VNF instance
Description: Scale-in or scale-out for VNF instance.
Method type: POST
URL for the resource: /vnflcm/v2/vnf_instances/{vnfInstanceId}/scale
Request:

Data type	Cardinality	Description
ScaleVnfRequest	1	Parameters for the scale VNF operation.

Attribute name	Data type	Cardinality	Supported in API v2	Supported in API v1	Description
type	Enum	1	Yes	Yes	Indicates the type of the scale operation requested. Permitted values: SCALE_OUT: adding additional VNFC instances to the VNF to increase capacity. SCALE_IN: removing VNFC instances from the VNF in order to release unused capacity.
aspectId	IdentifierInVnfd	1	Yes	Yes
numberOfSteps	Integer	0..1	Yes	Yes
additionalParams	KeyValuePairs	0..1	Yes	Yes
>is_reverse	Boolean	0..1	No	Yes	Tacker original attribute

Response:

Data type	Cardinality	Response Codes	Description
n/a		Success: 202	The request has been accepted for processing.
ProblemDetails	0..1	Error: 404	The API producer did not find a current representation for the target resource or is not willing to disclose that one exists.
ProblemDetails	1	Error: 409	The operation cannot be executed currently, due to a conflict with the state of the resource.
ProblemDetails	See clause 6.4 of¹¹	Error: 4xx, 5xx	Any common error response code as defined in clause 6.4 of ETSI GS NFV-SOL 013¹² may be returned.

Name: Heal a VNF instance
Description: Heal for VNF instance.
Method type: POST
URL for the resource: /vnflcm/v2/vnf_instances/{vnfInstanceId}/heal
Request:

Data type	Cardinality	Description
HealVnfRequest	1	Parameters for the heal VNF operation.

Attribute name	Data type	Cardinality	Supported in API v2	Supported in API v1	Description
vnfcInstanceId	Identifier	0..N	Yes	Yes	This attribute is defined in only SOL 002.
cause	String	0..1	Yes	Yes
additionalParams	KeyValuePairs	0..1	Yes	No
>all	Boolean	0..1	Yes	No	Tacker original attribute
healScript	String	0..1	No	No	This attribute is defined in only SOL 002.

Response:

Data type	Cardinality	Response Codes	Description
n/a		Success: 202	The request has been accepted for processing.
ProblemDetails	0..1	Error: 404	The API producer did not find a current representation for the target resource or is not willing to disclose that one exists.
ProblemDetails	1	Error: 409	The operation cannot be executed currently, due to a conflict with the state of the resource.
ProblemDetails	See clause 6.4 of¹³	Error: 4xx, 5xx	Any common error response code as defined in clause 6.4 of ETSI GS NFV-SOL 013¹⁴ may be returned.

Name: Modify VNF information
Description: Update information about a VNF instance.
Method type: PATCH
URL for the resource: vnflcm/v2/vnf_instances/{vnfInstanceId}
Request:

Data type	Cardinality	Description
VnfInfoModificationRequest	1	Parameters for the VNF modification.

Attribute name	Data type	Cardinality	Supported in API v2	Supported in API v1	Description
vnfInstanceName	String	0..1	Yes	Yes
vnfInstanceDescription	String	0..1	Yes	Yes
vnfPkgId	Identifier	1	No	Yes	Although this attribute is not available in SOL 002/003 v2.6.1, Tacker support it in v1 API. See note.
vnfdId	Identifier	0..1	Yes	Yes
vnfConfigurableProperties	KeyValuePairs	0..1	Yes	No
metadata	KeyValuePairs	0..1	Yes	Yes
extensions	KeyValuePairs	0..1	Yes	No
vimConnectionInfo	map(VimConnectionInfo)	0..N	Yes	Yes	This attribute is defined in only SOL 003.
>vimId	Identifier	0..1	Yes	Yes
>vimType	String	1	Yes	Yes
>interfaceInfo	KeyValuePairs	0..1	Yes	Yes
>accessInfo	KeyValuePairs	0..1	Yes	Yes
>extra	KeyValuePairs	0..1	Yes	No
vnfcInfoModifications	VnfcInfoModifications	0..N	Yes	No	This attribute is defined in only SOL 002.
>id	IdentifierInVnf	1	Yes	No
>vnfcConfigurableProperties	KeyValuePairs	1	Yes	No

Note

vnfPkgId is not available in SOL 002/003 v2.6.1. It is available in v2.4.1. However, Tacker have supported it for some NFV related equipment, utilizing v2.4.1 API.

Response:

Data type	Cardinality	Response Codes	Description
n/a		Success: 202	The request has been accepted for processing.
ProblemDetails	1	Error: 409	The operation cannot be executed currently, due to a conflict with the state of the resource.
ProblemDetails	See clause 6.4 of¹⁵	Error: 4xx, 5xx	Any common error response code as defined in clause 6.4 of ETSI GS NFV-SOL 013¹⁶ may be returned.

Note

Since current Tacker does not support http Etag, it does not support Error Code: 412 Precondition Failed. According to the ETSI NFV SOL document, there is no API request/response specification for Etag yet, and transactions using Etag are not defined by standardization. Tacker will support Etag after the ETSI NFV specification defines relevant transactions.

Name: Change external VNF connectivity
Description: Change the external connectivity of a VNF instance.
Method type: POST
URL for the resource: /vnflcm/v2/vnf_instances/{vnfInstanceId}/change_ext_conn
Request:

Data type	Cardinality	Description
ChangeExtVnfConnectivityRequest	1	Parameters for the change external VNF connectivity.

Attribute name	Data type	Cardinality	Supported in API v2	Supported in API v1	Description
extVirtualLinks	ExtVirtualLinkData	1..N	Yes	Yes
>id	Identifier	1	Yes	Yes
>vimConnectionId	Identifier	0..1	Yes	Yes
>resourceProviderId	Identifier	0..1	Yes	No
>resourceId	IdentifierInVim	1	Yes	Yes
>extCps	VnfExtCpData	1..N	Yes	Yes
>>cpdId	IdentifierInVnfd	1	Yes	Yes
>>cpConfig	map(VnfExtCpConfig)	1..N	Yes	Yes
>>>parentCpConfigId	IdentifierInVnf	0..1	Yes	Yes
>>>linkPortId	Identifier	0..1	Yes	Yes
>>>cpProtocolData	CpProtocolData	0..N	Yes	Yes
>>>>layerProtocol	Enum	1	Yes	Yes	Permitted values: IP_OVER_ETHERNET.
>>>>ipOverEthernet	IpOverEthernetAddressData	0..1	Yes	Yes
>>>>>macAddress	MacAddress	0..1	Yes	Yes
>>>>>segmentationId	String	0..1	Yes	not defined	New attribute in API v2.
>>>>>ipAddresses	Structure	0..N	Yes	Yes
>>>>>>type	Enum	1	Yes	Yes	Permitted values: IPV4, IPV6.
>>>>>>fixedAddresses	IpAddress	0..N	Yes	Yes
>>>>>>numDynamicAddresses	Integer	0..1	Yes	Yes
>>>>>>addressRange	Structure	0..1	Yes	Yes
>>>>>>>minAddress	IpAddress	1	Yes	Yes
>>>>>>>maxAddress	IpAddress	1	Yes	Yes
>>>>>>subnetId	IdentifierInVim	0..1	Yes	Yes
>extLinkPorts	ExtLinkPortData	0..N	Yes	Yes
>>id	Identifier	1	Yes	Yes
>>resourceHandle	ResourceHandle	1	Yes	Yes
>>>vimConnectionId	Identifier	0..1	Yes	Yes
>>>resourceProviderId	Identifier	0..1	Yes	No
>>>resourceId	IdentifierInVim	1	Yes	Yes
>>>vimLevelResourceType	String	0..1	Yes	Yes
vimConnectionInfo	map(VimConnectionInfo)	0..N	Yes	Yes	This attribute is defined in only SOL 003.
>vimId	Identifier	0..1	Yes	Yes
>vimType	String	1	Yes	Yes
>interfaceInfo	KeyValuePairs	0..1	Yes	Yes
>accessInfo	KeyValuePairs	0..1	Yes	Yes
>extra	KeyValuePairs	0..1	Yes	No
additionalParams	KeyValuePairs	0..1	Yes	Yes

Response:

Data type	Cardinality	Response Codes	Description
n/a		Success: 202	The request has been accepted for processing.
ProblemDetails	1	Error: 409	The operation cannot be executed currently, due to a conflict with the state of the resource.
ProblemDetails	See clause 6.4 of¹⁷	Error: 4xx, 5xx	Any common error response code as defined in clause 6.4 of ETSI GS NFV-SOL 013¹⁸ may be returned.

Security impact

None

Notifications impact

None

Other end user impact

None

Performance Impact

None

Other deployer impact

None

Developer impact

None

Implementation

Assignee(s)

Hirofumi Noguchi <hirofumi.noguchi.rs@hco.ntt.co.jp>

Work Items

Add new attributes supported by v2 API to python-tackerclient.
Add new version API endpoints to Tacker-server.
Implement new version API processings for Tacker-conductor.
Add new unit and functional tests.
Update the Tacker's API reference.

Dependencies

None

Testing

Unit and functional test cases will be added for VNF lifecycle management of VNF instances.

Documentation Impact

New supported APIs need to be added into Tacker API reference.

References

https://www.etsi.org/technologies-clusters/technologies/NFV ↩︎
https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/02.06.01_60/gs_nfv-sol002v020601p.pdf (Chapter 5: VNF Lifecycle Management interface)↩︎
https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/02.06.01_60/gs_nfv-sol003v020601p.pdf (Chapter 5: VNF Lifecycle Management interface)↩︎
https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/03.03.01_60/gs_nfv-sol002v030301p.pdf (Chapter 5: VNF Lifecycle Management interface)↩︎
https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/03.03.01_60/gs_nfv-sol003v030301p.pdf (Chapter 5: VNF Lifecycle Management interface)↩︎
https://specs.openstack.org/openstack/tacker-specs/specs/xena/support-nfv-solv3-start-and-terminate-vnf.html ↩︎
https://specs.openstack.org/openstack/tacker-specs/specs/xena/support-nfv-solv3-get-information.html ↩︎
https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/011/03.03.01_60/gs_nfv-sol011v030301p.pdf ↩︎
https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/002/03.03.01_60/gs_nfv-sol002v030301p.pdf (Chapter 5: VNF Lifecycle Management interface)↩︎
https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/003/03.03.01_60/gs_nfv-sol003v030301p.pdf (Chapter 5: VNF Lifecycle Management interface)↩︎
https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/013/03.04.01_60/gs_nfv-sol013v030401p.pdf ↩︎
https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/013/03.04.01_60/gs_nfv-sol013v030401p.pdf ↩︎
https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/013/03.04.01_60/gs_nfv-sol013v030401p.pdf ↩︎
https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/013/03.04.01_60/gs_nfv-sol013v030401p.pdf ↩︎
https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/013/03.04.01_60/gs_nfv-sol013v030401p.pdf ↩︎
https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/013/03.04.01_60/gs_nfv-sol013v030401p.pdf ↩︎
https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/013/03.04.01_60/gs_nfv-sol013v030401p.pdf ↩︎
https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/013/03.04.01_60/gs_nfv-sol013v030401p.pdf ↩︎

25 KiB Raw Blame History

Enhance NFV SOL_v3 LCM operation

Problem description

Proposed change

1) Flow of Scale VNF

2) Flow of Heal VNF

3) Flow of the Modify VNF Information

4) Flow of Change external VNF connectivity

Data model impact

REST API impact

Security impact

Notifications impact

Other end user impact

Performance Impact

Other deployer impact

Developer impact

Implementation

Assignee(s)

Work Items

Dependencies

Testing

Documentation Impact

References

25 KiB

Raw Blame History