Problems to be Solved before NFV scale deployment

Source: Internet
Author: User

Problems to be Solved before NFV scale deployment

NFV is a key technology for enabling network restructuring. Since the establishment of etsi isg nfv in early 2013, the NFV framework and series of specifications have been designed, it has gone through the innovation promotion period and high expectation period of Gartner's technology maturity curve, and has gradually turned to steady development. After nearly two years of development for vIMS, vEPC, the lab testing and current network pilot of vBRAS and other professional virtual networks are not yet available for commercial use in a large scale, including operators and vendors who have begun to exercise more caution in promoting the implementation of NFV.

NFV initially aims to achieve hardware resources sharing among multiple network systems through soft and hardware decoupling. On the one hand, IT introduces large-scale standardized general IT infrastructure to reduce costs, on the other hand, new businesses are accelerated through software deployment. The ideal is beautiful, and the reality is very skinny. During the implementation and deployment process, we found that: CT systems and IT systems are significantly different in terms of design methods, scale and complexity, reliability requirements, interoperability requirements, and operation and maintenance. IT technology and thinking methods are used to solve CT problems, it may be a bit unacceptable.

In order to realize the real large-scale deployment of NFV, the following problems need to be solved:

1. Improved NFV forwarding performance and reliability

The CT system has higher performance requirements than the IT system. CT network elements can be divided into control and forwarding.

Control Network elements need to provide high reliability. Typical network elements, such as the mobility management entity MME of 4G core networks, are responsible for handling signaling interactions between 4G users accessing the mobile core network, this includes key control functions such as authentication access control and mobility management, without forwarding user business data. Therefore, MME-based traffic features low traffic, high concurrency, and high reliability requirements. Traditional Physical MME devices can process more than one million concurrent user sessions at the same time. If you replace X86 servers with vMME, you must deploy multiple servers and provide load balancing and high-reliability HA solutions.

Forwarding network elements need to provide high-throughput line-rate forwarding. Typical network elements such as the broadband remote access server BRAS are responsible for broadband service access control and traffic aggregation and forwarding. BRAS has a variety of virtualization modes, typical of which include: Switch-control separation vBRAS, using X86-based control plane and proprietary forwarding plane devices based on NP proprietary devices or programmable white box switches, that is, only the control plane virtualization is realized. The standard X86-Based Integrated pure soft vBRAS; the control plane is based on the standard X86 server and the forwarding plane is based on the X86 server with the acceleration hardware. VBRAS, which only performs control plane virtualization, are essentially no different from traditional physical BRAS, but only implement centralized IP address control and Device Configuration Management, it is impossible to change the long release cycle of R & D, procurement, and deployment of proprietary devices. Based on the integrated vBRAS of General X86 servers, even if the DPDK and Other Software Acceleration technologies are applied, from the perspective of forwarding performance, it is far from the line-rate forwarding achieved by a single board of Traditional Physical BRAS equipment, therefore, X86-Based Integrated vBRAS is mainly used to carry small-traffic large sessions such as ITMS, but cannot carry home broadband Internet access, IPTV and other services. The use of X86 servers and smart acceleration hardware to improve vBRAS forwarding performance has become an important solution for vBRAS to carry full business. However, hardware acceleration will inevitably reduce the universality of NFVI, the special requirements for NFVI for specific CT network elements seem to violate the NFV's original intention.

From the perspective of scale, the deployment scale of forwarding network elements must be far beyond the deployment scale of control network elements. The cost of NFVI is closely related to the IT infrastructure scale, server shipments directly affect the purchase price. Therefore, the economic benefit of NFV depends on large-scale deployment. Only after the virtual deployment of forwarding network elements can NFV be implemented on a large scale. From this point of view, the use of hardware acceleration technology to solve the NFVI forwarding performance issues, it seems that the only way, is the need of CT network elements for NFVI. Using pluggable smart NICs to uninstall some software functions to reduce the consumption of CPU and PCIe bandwidth is a relatively common hardware acceleration solution worth looking forward. As a smart Nic, it is also divided into multiple products based on ARM architecture and FPGA. Because FPGA is powerful and programmable repeatedly, on the one hand, it achieves the forwarding performance comparable to that of the X86 vBRAS and the physical BRAS card, on the other hand, it supports the development and deployment of new functions in the future, it is more in line with the concept that NFV uses general hardware and rapid software deployment. However, the price of FPGA smart NICs also depends on shipments. Currently, it is much more expensive than ordinary NICs, but in the future, if we can form an industrial chain and large-scale commercial use, it is feasible to comprehensively consider the cost saved by the CPU and the cost increased by the smart Nic.

2. NFV decoupling and standardization

NFV expects that the benefits of unified infrastructure, rapid deployment of new businesses, and a more open ecosystem must all be achieved through decoupling. Decoupling between two layers of hardware and software is the most basic goal, otherwise there is no essential difference with traditional integrated proprietary devices. However, according to the NFV framework and Industry Development defined by ETSI, The NFV industry chain can be divided into more layers:

  • Hardware: Server vendor
  • Platform: Hypervisor vendor
  • Functional software + Management: VNF + VNFM + VIM vendor. Because these three modules interact frequently and there is a binding relationship between them, VNF manufacturers usually provide VNFM and VIM at the same time.
  • Orchestration: NFVO. Because global management of network services and resources across manufacturers is required, many operators choose to develop their own NFVO, or choose a relatively neutral third-party manufacturer for in-depth custom development.

In order not to be bound by a few manufacturers and to perform cross-factory orchestration management, the above four parts must be decoupled. There are two criteria for successful decoupling: first, modules from different vendors can communicate with each other to implement the basic business functions of the NFV network; second, functional software can achieve stable and consistent performance on different hardware and platforms, meeting NFV network performance requirements.

The decoupling and cross-vendor interconnection of complex communication systems rely on globally unified technical standards. Only when everyone follows the same bit-level technical standards can the communication between two communication devices be completed. 3GPP is undoubtedly the most successful international communication standards organization. It defines GSM, WCDMA, LTE/EPC as well as the 5g standard to be released, it laid the foundation for R & D and large-scale deployment of several generations of global mobile communication systems. Strictly speaking, etsi isg nfv does not define international standards, but guides general industry norms of the NFV industry. The standard definition of ETSI is generally carried out in stages. Since the beginning of 2013, the NFV specification has completed two stages of definition and is currently in the third stage. From the introduction of concepts to the definition of architectures, functions, interfaces and information models, NFV specifications are constantly being improved, however, the specifications output in the first two stages are not enough to serve as the basis for interconnection between modules. The work in the third stage is more intense due to how the products of various manufacturers are changed, traditional equipment vendors familiar with standard communication do not have the motivation to Promote the Development of NFV standards, which leads to a poor standard development. On the other hand, NFV-related open-source projects were originally brutal growth. Whoever made them into fact standards had the final say, and even more dispersed, and the Linux foundation began to integrate its major projects. Open-source code-based products also have proprietary Optimization development from various manufacturers. There are too many uncertainties and it is difficult to become a commercial product in the CT field.

Based on the above reasons, only simple network elements such as integrated vBRAS can be fully decoupled from NFV, and operators have spent a lot of energy to promote the integration of various manufacturers one by one. As a more complex system, such as vIMS and vEPC, more work is needed to achieve full decoupling.

3. NFV networks can be purchased and operated

At present, domestic operators generally perform rolling planning and collection of professional traditional network equipment on an annual basis. Before entering the procurement stage, these network devices generally accept the carrier's collection test in the black box mode. After the test is passed, the devices are bidding. After the bidding is successful, the devices are sent to the carrier's provincial and municipal companies, and then enter the data center installation and configuration loading services. From testing to procurement, to delivery and online deployment of devices in different provinces and cities, the cycle is long, and the price and configuration of the winning product are often inconsistent. The emergence of NFV is also to make up for the shortcomings of traditional equipment procurement and operation. We hope to purchase and deploy a unified resource pool, and then quickly deploy the network functions in software mode to accelerate business release. However, after stratified decoupling, the NFV network also needs to be decoupled from procurement to operation.

First of all, from the perspective of collection testing, stratified decoupling requires testing of the functions and performance of various combinations. The testing workload will multiply with the increase of each manufacturer, each update of the software and platform version also involves re-Traversing various combinations of tests. To meet the future NFV network's collection and testing requirements, we must build a comprehensive test bed covering all the specialties and adopt automated integration testing methods.

Second, traditional network equipment is provided by a single manufacturer, so it is duty-bound to handle any problems. More manufacturers are introduced after the layer-wise decoupling of NFV networks. In the event of a fault, you must first identify which layer has encountered a problem. Otherwise, different manufacturers may easily shirk their responsibilities. Compared with hardware problems, software problems are more difficult to locate. If multiple manufacturers are involved in software cooperation, it is difficult to draw objective conclusions on which party should modify the problems.

Therefore, in the future, NFV Network procurement and operation require the operator to have powerful system integration capabilities, as well as adjustments to the organizational structure, business processes, and division of responsibilities.

To sum up, NFV networks also need to solve forwarding performance and reliability, decoupling and interoperability standard formulation, procurement and operation issues before large-scale commercial deployment. The operator's network restructuring affects the entire communication industry. It is expected to work with the entire industry to solve the above problems and promote the implementation and implementation of network restructuring.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.