Drivenets Network Cloud is Becoming the Industry Standard

On May 27^th, the Telecom Infra Project (TIP) announced the publication of a technical requirements document defining a disaggregated distributed backbone router (DDBR). This architecture is the result of collaboration among Vodafone, Telefonica, MTN and KDDI, four leading communications service providers (CSPs) working to set the industry in the “right” direction. TIP’s intention is to avoid the traditional, vendor-led, siloed implementations tolerated by the industry for the last few decades.

Telecom Infra Project sets industry standards

TIP operates in a way that allow CSPs to bring their expertise and requirements together in a vendor-free research-oriented discussion. The idea is to create a generic definition that makes the most sense for solving the majority of problems encountered by network operators with one important note – TIP definitions are based on open and disaggregated architecture.

Three points are mentioned as the key reasons for TIP operators to define and complete these generic definitions – scalability, total cost of ownership (TCO) and use case flexibility. These three pillars also describe the differences between cloud and monolithic infrastructure models. Let’s park that thought here for a while and come back to it later.

The next step is to have vendors included in the process by answering the requirement sheet in a simple RFI phase. This is when DriveNets and a group of other vendors first got their eyes on TIP’s DDBR definition.

DriveNets joins the networking industry

DriveNets came to the world in early 2016 with the mission of implementing the best virtual router as a network function. Like many other network function virtualization (NFV) implementations, ours also failed initially to meet the requirements of commercial deployments. While flexibility is a given since our implementation is pure software, and scale is achievable since it runs on multiple servers, it was the TCO angle that initially was missing to complete a successful triangle.

NFV spoiler alert: building a network function (NF) that is based on hardware not fitted to run as a network is conceptually inefficient. Apply this to any NFV variant you are familiar with and you will find a disturbing correlation between network orientation (vs. function orientation) of the NFV variant and its market success.

Defining DriveNets Network Cloud

Focusing on TCO, scale, and flexibility, we embarked on a journey that led us to define the DriveNets Network Cloud. Here are a few milestones we passed along our path toward disrupting the traditional way of building networks.

First, we understood that the same solution should fit into any network location and use case in order to avoid the (too) large variety of routers in the network. The size and functionality can vary but the same standard devices should be used throughout the network as described in the following figure:

Figure 1. Disaggregated Open Router Scope

The opportunity is an outcome of new services and use cases supported by 5G, such as massive IoT and mission-critical applications. This is an opportunity to serve new target markets and create new revenue streams, in an effort to monetize 5G infrastructure and services.

Second, the monolithic coupling of the data, control and management planes need to be distributed and controlled independently from one another in order to allow each to perform and scale without cross-influencing each other. The monolithic coupling of these planes is described in figure #2 below:

Figure 2. Monolithic IP Backbone Routers

Our third realization is that scaling up the network within a single box is limited, and a scale-out type of topology is required in order to maximize ASIC capabilities and fulfill network demands. The problematic nature of scaling up within a single box is shown in figure #3, while a preferred scale-out topology is shown in figure #4 below:

Figure 3. Traditional scale-up path

Figure 4. Disaggregated Spine & Leaf Architecture

Our fourth insight is the importance of using white boxes while separating the control plane from the data plane device and moving it to a dedicated compute resource as illustrated in figure 5:

Figure 5. Distributed Disaggregated Backbone Router

This separation allows the control plane to scale and evolve in a flexible manner independently from the lower cost white box-based data plane.

Building the network infrastructure of the future

Now let’s circle back to our “parked” item of the three pillars defining a cloud infrastructure – TCO, scale and flexibility. DriveNets focused on these three pillars as we were looking to build the network infrastructure of the future, which we call DriveNets Network Cloud.

I’d like to add a few last words about closing the loop. The ideas and realizations above drove DriveNets’ evolution, resulting in the DriveNets Network Cloud solution. Having said that, the figures pasted into this article as reasoning for how the industry should evolve the world of networking are all taken from the TIP DDBR Technical Requirements Document.

I guess it’s safe to say that whether you call it DDBR, distributed disaggregated chassis (DDC) or Network Cloud, when the basic logic of the architecture simply “works” then it’s bound to become the industry standard.