Support VNF update operations based on ETSI NFV-SOL specification

https://blueprints.launchpad.net/tacker/+spec/support-etsi-nfv-specs

ETSI specifications within the NFV Architecture Framework [1] describe the main aspects of NFV development and usage based on of 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.

Problem description

In the current Tacker implementation based on ETSI NFV-SOL, Tacker uses its own API which describes VNF update operations which is Ability to execute a VNF application software modification.

However, these operations are not aligned with the current ETSI NFV data-model. As a result, there might be lack of compatibility with 3rd party VNFs [4], as they are developed according to ETSI NFV specifications. 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.

Proposed change

Introduce a new interface for updating information about a VNF instance.

The operation provided through this interface is: * Modify VNF

The following items can be updated by this operation.: - vnfInstanceName - vnfInstanceDescription - vnfdId - metadata - vimConnectionInfo

1) Flow of the Modify VNF Information operation (change vnfdId)

Precondition: The resource representing the VNF instance has been created. The VNF Package used for “Modify VNF” has been onboarded in NFVO.

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

  1. The Client sends a PATCH request to the “Individual VNF instance” resource.

  2. If VNFM does not have target VNF Package, VNFM gets it from NFVO.

  3. VNFM sends to the Client a VNF lifecycle management operation occurrence notification with the “PROCESSING” state to indicate the processing occurrence of the lifecycle management operation.

  4. The VNFM has finished the modification operation.

  5. VNFM sends to the Client a VNF lifecycle management operation occurrence notification with the “COMPLETED” state to indicate the completion occurrence of the lifecycle management operation.

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

2) Flow of the Modify VNF Information operation (Other changes)

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

  1. The Client sends a PATCH request to the “Individual VNF instance” resource.

  2. VNFM sends to the Client a VNF lifecycle management operation occurrence notification with the “PROCESSING” state to indicate the processing occurrence of the lifecycle management operation.

  3. The VNFM has finished the modification operation.

  4. VNFM sends to the Client a VNF lifecycle management operation occurrence notification with the “COMPLETED” state to indicate the completion occurrence of the lifecycle management operation.

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

Alternatives

None

Data model impact

Modify following tables in current ‘tacker’ database. The corresponding schemas are detailed below:-

vnf_instances::

vnf_metadata vnf_metadata json

REST API impact

The following restFul API will be added. This restFul API will be based on ETSI NFV SOL002 [2] and SOL003 [3].

  • Name: Modify VNF Instances
    Description: Modify an Individual VNF instance resource.
    Method type: PATCH
    URL for the resource: /vnflcm/v1/vnf_instances/{vnfInstanceId}
    Request: Resource URI variables for this resource

    Name

    Description

    VnfModificationRequest

    Identifier of the VNF instance to be modified.
    Request:

    Data type

    Cardinality

    Description

    VnfModificationRequest

    1

    Parameters for the Scale VNF operation.

    Attribute name

    Data type

    Cardinality

    Supported in (V)

    vnfInstanceName

    String

    0..1

    Yes

    vnfInstanceDescription

    String

    0..1

    Yes

    vnfPkgId

    Identifier

    1

    Yes

    vnfdId

    Identifier

    1

    Yes

    vnfConfigurableProperties

    KeyValuePairs

    0..1

    No

    vimConnectionInfo

    VimConnectionInfo

    0..N -> 0..1

    Yes

    metadata

    KeyValuePairs

    0..1

    Yes

    extensions

    KeyValuePairs

    0..1

    No

    vnfcInfoModifications

    VnfcInfoModificartions

    0..1

    No

    vnfcInfoModificationsDeleteIds

    Identifier

    0..N

    No

    vimConnectionInfoDeleteIds

    Identifier

    0..N

    No

    Note

    vnfPkgId is not available in SOL 002 /003 v2.6.1 but in v2.4.1. However, most NFV related equipment, such as NFVO, still utilize v2.4.1 API and this attribute is mondatory for executing VNF update operation. So, Tacker will support vnfPkgId in Victoria release. Whether or not continue to support v2.4.1 API and attributes for the future release will be decided based on the requirements of service providers and the situation of NFV product.

    Note

    vimConnectionInfo shows multiple VIMs per VNF. However due to the partial support of this feature in the ETSI present release, the number of entries in the VIMs attribute is not greater than 1.

    Response:

    Data type

    Cardinality

    Response Codes

    Description

    n/a

    n/a
    Success 202
    Error 409

    The request was accepted for processing, but the processing has not been completed.

    Note

    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. Therefore, the Victoria release does not support Error Code: 412 Precondition Failed. Once a standard specification for this is established, it will be installed on the tacker.

Security impact

None

Notifications impact

None

Other end user impact

Add new OSC commands in python-tackerclient to invoke VNF update operations of VNF instances API.

Performance Impact

None

Other deployer impact

The previously created VNFs will not be allowed to be managed using the newly introduced APIs.

Developer impact

None

Implementation

Assignee(s)

Primary assignee:

Keiko Kuriu <keiko.kuriu.wa@hco.ntt.co.jp>

Work Items

  • Add new REST API endpoints to Tacker-server for VNF update operations of VNF instances.

  • Make changes in python-tackerclient to add new OSC commands for calling updating operations of VNF instances restFul APIs.

  • Add new unit and functional tests.

  • Change API Tacker documentation.

Dependencies

None

Testing

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

Documentation Impact

Complete user guide will be added to explain how to invoke VNF lifecycle management of VNF instances with examples.

References