The practice of NFV decoupling test
draft-long-nfvrg-nfv-decoupling-test-01

Abstract

This document mainly introduces the practice of NFV decoupling test. Based on the product development situation of the current vendors, the decoupling test is carried out between NFVI&VIM, VNFM&VNF and NFVO. Through a series of tests to explore some of the problems encountered in the current stage of NFV decoupling testing, provide ideas for the subsequent development of NFV products.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on December 27, 2019.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Decoupling test of NFV
• 3.1. Introduce of NFV decoupling test
• 3.2. NFV decoupling test architecture
• 4. Decoupling test of NFV
• 5. Informative References
• Authors' Addresses

1. Introduction

3GPP has adopted the R15 standard and the SBA (Service Based Architecture) architecture, which further splits multiple NFs(Network Functions) in the 5G core network into multiple NFS (Network Function Service), each NFS has the characteristics of independent autonomy. But the existence of multiple NFSs in the clouded NFV also brings compatibility problems. Therefore, one of the key requirements of the 5G core network for the clouded NFV platform is open. The cloud platform needs to implement decoupling deployment and network resource sharing, thus not only avoiding the lock-up of single-vendors but also can build an open ecosystem based on open source projects.

But, there are still many problems in the decoupling of the clouded NFV platform. The interfaces of different vendors are not standardized and are not unified, which makes it difficult for the components of the NFV platform to properly connect and provide complete services. According to the [ETSI_GS_NFV_002], it divides the NFV into multiple modules as shown in Figure 1.

• Virtualized Network Function (VNF).
• Element Management (EM).
• NFV Infrastructure, including: Hardware and virtualized resources, and Virtualization Layer.
• Virtualized Infrastructure Manager(s) (VIM).
• NFV Orchestrator.
• VNF Manager(s).
• Service, VNF and Infrastructure Description. Operations and Business Support Systems (OSS/BSS).

 
                                               +--------------------+
+-------------------------------------------+  | +--------------+   |
|                 OSS/BSS                   |  | | NFV          |   |
+-------------------------------------------+  | | Orchestrator +-+ |
                                               | +--+-----------+ | |
+-------------------------------------------+  |    |             | |
|  +-------+     +-------+     +-------+    |  |    |             | |
|  | EM 1  |     | EM 2  |     | EM 3  |    |  |    |             | |
|  +---+---+     +---+---+     +---+---+    |  | +--+---------+   | |
|      |             |             |        +----+    VNF     |   | |
|  +---+---+     +---+---+     +---+---+    |  | | manager(s) |   | |
|  | VNF 1 |     | VNF 2 |     | VNF 3 |    |  | +--+---------+   | |
|  +---+---+     +---+---+     +---+---+    |  |    |             | |
+------|-------------|-------------|--------+  |    |             | |
       |             |             |           |    |             | |
+------+-------------+-------------+--------+  |    |             | |
|         NFV Infrastructure (NFVI)         |  |    |             | |
| +---------+    +---------+    +---------+ |  |    |             | |
| | Virtual |    | Virtual |    | Virtual | |  |    |             | |
| | Compute |    | Storage |    | Network | |  |    |             | |
| +---------+    +---------+    +---------+ |  | +--+-----+       | |
| +---------------------------------------+ |  | |        |       | |
| |         Virtualization Layer          | |--|-| VIM(s) +-------+ |
| +---------------------------------------+ |  | |        |         |
| +---------------------------------------+ |  | +--------+         |
| | +---------+  +---------+  +---------+ | |  |                    |
| | | Compute |  | Storage |  | Network | | |  |                    |
| | | hardware|  | hardware|  | hardware| | |  |                    |
| | +----------  +---------+  +---------+ | |  |                    |
| |          Hardware resources           | |  |  NFV Management    |
| +---------------------------------------+ |  | and Orchestration  |
+-------------------------------------------+  +--------------------+
                    Figure 1: ETSI NFV architecture

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC8174].

NFVI&VIM, NFV Infrastructure and VIM.

VNFM, VNF Manager.

NFVO, NFV Orchestrator.

3. Decoupling test of NFV

3.1. Introduce of NFV decoupling test

In the ETSI NFV architecture, there are corresponding interfaces between each modules. There will be a problem of interface compatibility between the components as shown in the figure 1. Decoupling tests are required to ensure that the decoupled components can be properly integrated. According to the current vendors' development, the main decoupling are between NFVI&VIM, VNFM&VNF and NFVO.

Operators will generally develop NFVO to ensure compatibility with existing OSS/BSS, VNF vendors trend to better control VNF, so they will provide VNFM with VNF, and the underlying virtualization management VIM vendors will also provide self-developed or generic x86 servers as a whole NFV resource pool cloud solution. Therefore, the decoupling of clouded NFV is simplified to the following figure 2.

 
                                               +--------------------+
                                               |                    |
                                               |  NFV Orchestrator  +--+
                                               |                    |  |
                                               +----------+---------+  |
                                                          |            |
+-------------------------------------------+  +----------+---------+  |
|  +-------+     +-------+     +-------+    |  |          |         |  |
|  | EM 1  |     | EM 2  |     | EM 3  |    |  |          |         |  |
|  +---+---+     +---+---+     +---+---+    |  |   +------+-----+   |  |
|      |             |             |        +--|---|    VNF     |   |  |
|  +---+----     +---+---+     +---+---+    |  |   | manager(s) |   |  |
|  | VNF 1 |     | VNF 2 |     | VNF 3 |    |  |   +------+-----+   |  |
|  +---+---+     +---+---+     +---+---+    |  |          |         |  |
+------|-------------|-------------|--------+  +----------|---------+  |
                     |                                    |            |
+--------------------+------------------------------------+---------+  |
|                                                                   |  |
|   +-----------------------------------------------------------+   |  |
|   |                         NFVI&VIM(s)                       +---+--+
|   +-----------------------------------------------------------+   |
|                                                                   |
+-------------------------------------------------------------------+
                Figure 2: Simplified NFV decoupling architecture

In addition, from the perspective of VNFM, the scheduling of VIM resources is divided into direct mode and indirect mode. NFVO sends messages to VNFM and VNFM operates VIM to allocate VNF resources is direct mode. In contrast, the way NFVO directly operates the VIM to allocate the resources required by the VNF is considered an indirect mode. This causes NFVO must to support different VNFM operating modes.

3.2. NFV decoupling test architecture

The NFV decoupling test practice selects NFVI&VIM, VNF&VNFM and NFVO vendors for interoperability tests. The main test content is functional testing, such as: VNF lifecycle management (VNFD onboard, VNF instantiate, VNF scale in/out, VNF terminate), VNF self-healing, VNF update, VNF error management.

The test specification and testcases are reference to ETSI's NFV standard [ETSI_NFV_TST_002] and [ETSI_NFV_TST_007]. The operator C's NFVO is used as the unified orchestration layer, the vendors F and H's VNF&VNFM as network elements and VNF management, and the vendor F's infrastructure is tested as the underlying virtualization infrastructure. The decoupling test architecture is shown in figure 3.

 
                                   +----------------+
                                   |    Vendor      +--+
                                   |      C         |  |
                                   +------+---------+  |
                                          |            |
                +---------------+  +------+---------+  |
                |    Vendor     +--+    Vendor      |  |
                |      H        |  |      H         |  |
                +------+--------+  +------+---------+  |
                       |                  |            |
                +------+------------------+---------+  |
                |              Vendor               +--+
                |                F                  |
                +-----------------------------------+
              Figure 3: NFV decoupling test architecture

4. Decoupling test of NFV

The test results are shown in the following table 1.

The test results show that under the ETSI NFV standards, the basic interoperability tests such as VNF onboard, instantiate, manual scale in/out and terminate, can be executed successfully, while the VNF self-healing, VNF update, VNF error management are failed due to VNFM and NFVO unconformable interface. The main reason is that the closure of the VNF vendors and the data exchange format reported by the state are inconsistent, usually only exchange data with their own NFVO. This exclusivity makes it difficult for the vendor's VNFM&VNF to communicate with the different NFVO vendors, especially some advance features, this has led operators to develop a variety of ways to obtain VNF status, and also encounter many compatibility issues when integration multi-vendor VNFs and VNFMs.

5. Informative References

Authors' Addresses