Legacy routers have been traditionally built with both data plane and control plane hosted in the same device, with data plane running in specialized ASICs hardware, and control plane running in an x86 architecture. This approach has historically enabled network operators to meet the capacity and feature requirements of their networks, but at a significant cost and overhead, including severe vendor lock-in, limited influence on innovation and product roadmaps, and cost-inefficient growth through scale-up mechanisms.
There have been several approaches and initiatives to address those limitations, including the creation of the Telecom Infra Project (TIP) initiative to foster innovation through open standards and open architectures, especially those that have been successful in the realm of webscalers and data centers, and that can be applied to telecom networks too. Among such initiatives, we can find disaggregated networking and Network Function Virtualization (NFV).
In disaggregated networking, control plane and data plane are provided by different vendors. For example, the data plane runs on white box switches using specialized ASICs from third-party vendors, and the control plane runs as part of the network operating system (NOS) of the white box, on an x86 processor. This approach reduces cost and vendor lock-in, but it still suffers from the same limited control plane resource problem that legacy routers have.
In NFV, the control plane of the router is implemented in x86 architectures in the cloud, either as virtual machines or containers, where CPU and RAM resources are plenty. The cloud environment is not as well suited for the data plane as it is for the control plane though. If the data plane runs in software on top of an x86 architecture, the achievable forwarding rates are not as high as the ones achieved with specialized ASICs, something especially relevant in telecom environments. In addition, cost per bit is also significantly higher in x86 servers than in white boxes, due to the use of dedicated NICs. Finally, delay-sensitive data plane functionality suffers when data traffic needs to go up from the network into the cloud for processing, and then come back to continue its path over the network.
Volta Networks tries to combine the best of both worlds by running the control plane in the cloud, where RAM and CPU resources are plenty, and the data plane in white boxes, where cost-effective, specialized ASICs enable the intended line rates and latency requirements.
Volta’s VEVRE enables network operators to use a combined x86-based and whitebox-based infrastructure to build distributed virtual routers at scale. It does so by running a distributed system of Network Functions (NF) that implements the control plane and data plane of a router, executing them in the most appropriate part of the combined infrastructure. For instance, the containerized NFs (CNFs) that implement the control plane run in x86 compute nodes, and the NFs that implement the data plane run in white boxes, as a combination of hardware functionality enabled by the Volta Agent through the white box’s chipset’s SDK, and a set of OS-level software processes that run delay-sensitive functionality.
Communication between control plane CNFs and data plane NFs occur both at the gRPC level, as well as at the packet level. For instance, data packets carrying control traffic information must reach the CNFs that run in the x86-based compute nodes and implement routing functionality. Moreover, given that Volta’s VEVRE enables multiple virtual routers over a single white box, both the Volta Agent running in a white box and its counterpart in the cloud must ensure that those control traffic packets flow through the proper virtual interfaces to enable the communication between the control plane CNFs and data plane NFs that are part of the same virtual router.
Volta’s VEVRE hides all this complexity from the user by exposing a high-level virtual router abstraction so that operators can just use VEVRE’s API to create and manage virtual routers via open standards such as NETCONF/YANG and gRPC (while at the same time still enabling network operators to troubleshoot when needed via the familiar CLI). External SDN controllers can then use Volta’s VEVRE to both create and operate these virtual routers.
This approach is a natural fit for TeraFlow, an H2020-based EU research project created by a consortium of companies to implement an SDN controller that supports network automation and network slicing use cases at scale. Automation at scale needs programmatic access to network elements such as the one Volta’s VEVRE provides for its virtual routers, and network slicing can be accomplished through the type of virtualization, that Volta’s VEVRE enables.
Volta is excited to work along with all of Teraflow’s members during the incoming months, including network operators such as Telefonica and Telenor, to help them accomplish their use cases through Volta’s innovative router virtualization approach.