The practice of NFV decoupling testBII Group Holdings Ltd.2nd Floor, Building 5, No.58 Jinghai Road, BDA, Beijing, ChinaBeijing101111P. R. Chinaylong@biigroup.cnBII Group Holdings Ltd.2nd Floor, Building 5, No.58 Jinghai Road, BDA, Beijing, ChinaBeijing101111P. R. Chinaysong@biigroup.cnBII Group Holdings Ltd.2nd Floor, Building 5, No.58 Jinghai Road, BDA, Beijing, ChinaBeijing101111P. R. Chinazjtang@biigroup.cn
Networking
nfvrgNFVNFV DecouplingNFV TestThis 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.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 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 ,
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).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 .NFVI&VIM, NFV Infrastructure and VIM.VNFM, VNF Manager.NFVO, NFV Orchestrator.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.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.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 and .
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.The test results are shown in the following table 1.TestcasesVendor FVendor HOnboardPASSPASSInstantiatePASSPASSScale in(manual)PASSPASSScale out(manual)PASSPASSTerminatePASSPASSThe 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.ETSI GS NFV 002: "Network Functions Virtualisation (NFV); Architectural Framework"ETSI NFV ISGETSI GS NFV-TST 002: "Network Functions Virtualisation (NFV); Testing Methodology;
Report on NFV Interoperability Testing Methodology."ETSI NFV ISGETSI GR NFV-TST 007: "Testing; Guidelines on Interoperability Testing for MANO."ETSI NFV ISG