By Chris Rice and John Medamana

“White box” is essentially a hardware device with no well-known brand name.

In telecom, this usually means a multi-function device like a router or switch created without an original equipment manufacturer (OEM). Generally, a different group provides the software than the one that builds the hardware. This is “decoupling” or disaggregation of the hardware and software.

Being able to mix and match standardized hardware configurations with different software protocols is a critical element of white box. It’s how you get a more open, flexible and cost-effective alternative to traditional proprietary, integrated networking equipment.

It’s a new approach to building telecom infrastructure. We think white box will play a big part in the future of our industry. Our goal is to help this ecosystem grow in a way that benefits everyone.

To do that, telecom companies need to get comfortable with taking more responsibility for the technologies powering their networks. We’re here to give a general overview of exactly where we think service providers need to get more involved to get the most out of the white box opportunity.

The decoupling of hardware and software

It all starts with the decoupling of hardware and software. For the white box ecosystem to scale, open interfaces on common hardware are required, as are operating system, control, management, and data plane protocol software. And a few other things need to happen. The hardware and software must come from a reliable set of suppliers, the interfaces on both the hardware and software must be open and well-defined, and the market for this new ecosystem must be strong, stable and self-sustaining.

A new way of doing things

Let’s look at the new emerging white box ecosystem and see how it compares to the existing approach to telecom equipment. You’ll see in Table 1 below, in the existing telecom ecosystem, the OEM controls the end solution and aggregates the needs of many service providers. The OEM is the hub of the requirements. It creates solutions that best fit the broader market based on the capabilities of custom silicon features. The service provider’s relationship with vendors has been described as that of a professional buyer.

In the emerging white box ecosystem, service providers take a much more active role in the end solution. They use the external ecosystem for key capabilities. They need to have a fundamental understanding of the various components. Service providers should be comfortable with their technical teams being deeply involved in the design details of the end solution. The biggest payoff is that the end solution will be modular and have open interfaces. These open interfaces are key to delivering automation.

Open interfaces provide access to required data. Data is turned into insights. Insights are filtered to take actions, possibly through a machine learning system, which when the loop is closed, delivers the required intelligent automation.

Other benefits include:

  • Lower CAPEX and OPEX for the new solution
  • Better visibility and input into the merchant silicon roadmap
  • Using original design manufacturers (ODMs) for hardware configurations
  • A growing, open hardware ecosystem in communities like the Open Compute Project (OCP)
  • Service providers can now customize the solution for their needs using premium components

New ownership options

The new ecosystem also provides different solution ownership options for service providers. Service providers can bring together the various pieces shown in the right side of Figure 1, essentially owning or controlling the integration, delivery and support for the entire solution. They can own the hardware solution and integrate best-of-breed software modules from different sources. In this model, the service provider owns the break-fix for the hardware as well as the integration and maintenance of software.

A second option for the service provider is to control the design and specification of hardware and software modules and use third party integrators for manufacturing, break-fix, integration, and maintenance services. But the service provider would control the design and choice of hardware and software modules.A third option is to specify exactly what elements are to be used and what features are desired, and buy the complete solution from a single entity, specifying which elements and features you want. This is essentially the same as the left side of Figure 1, but with 2 very important differences – there are open interfaces in this new model, and the solution can be made from best-of-breed components.

Table 1: Comparison of the Existing Telecom Equipment to the Emerging White box Ecosystem

Existing Telecom Equipment

New White Box Ecosystem


External Ecosystem

Service Provider (SP)


External Ecosystem

Service Provider (SP)

Controls end solution

Has little to no influence

Provides the requirements to OEM

Disaggregates their stack

Merchant silicon becomes key enabler

Works with merchant silicon providers on long-term roadmap

Solution has closed interfaces

Works with primarily with OEM

Has willingness to aggregate more best of breed components

Open interfaces in HW and SW are defined by industry

Has different levels of ownership options

Solution is an aggregate of different SPs needs


Works to drive OEM roadmap

Solution must have well-defined open interfaces

Reference designs become more common

Needs a more fundamental understanding of the telecom stack

Solution is typically built with proprietary silicon


Buys and integrates OEM solution

Solution is built on merchant silicon

Drive smart disaggregation of HW and SW


Figure 1: White box Layer Disaggregation

Breaking down the layers of the new ecosystem

As mentioned earlier, the new ecosystem must be strong, stable and self-sufficient to be viable. Let’s look at the various elements in Figure 1 and see what is required. Starting at the bottom, the merchant silicon, there are several strong, stable options for this layer, many delivering to the telecom and web scale industry today.

AT&T Chief Technology Officer Andre Fuetsch spoke about some of our initial white box work at the Open Networking Summit (ONS) in April. 

At ONS we highlighted Intel for its microprocessor and technology capabilities, and Broadcom and Barefoot Networks for their merchant silicon ASICs. Intel and Broadcom are long standing entities and Barefoot is one of many start-ups in this space, both of which speak to the health of the ecosystem at this layer.

For the next layer, the silicon interface, the place where the silicon features are abstracted and exposed to the higher layers of the stack, Snaproute is a start-up that has technology for this layer. There are options from the silicon companies themselves that expose their hardware abstraction layer (HAL) in a well-defined manner. Other options exist in open source, like Data Plane Development Kit (DPDK), Switch Abstraction Interface (SAI) and P4, which seek standard ways for abstracting the silicon chip’s data plane functionality.

The next layer, the hardware reference design, has many options. OCP provides reference designs for the industry, designs which one or more of its members have typically put into production. ODMs like Delta Electronics and Edgecore Networks are suppliers we used in our initial white box work. These companies and others make up a strong and stable ODM ecosystem for these new white box hardware systems.

The network operating system and associated protocols shown in Figure 1 at the top of the stack are critical elements of the new ecosystem, arguably the most important. This layer has typically been the domain of the OEMs with their proprietary network operating systems that “glue” all the silicon, associated hardware, low-level chip drivers, and networking application together. It is this layer that implements control and management plane functions allowing users and external systems to interact with the router. It is only the capabilities that are exposed here which are available to end users, regardless of what capabilities the silicon chip may have or what capabilities the low-level drivers can expose. The control and management plane protocols are implemented at this layer. It maintains routing and forwarding databases, allowing open interfaces for control plane protocols, enabling alarms and telemetry and exposing data plane capabilities.

There are new options emerging here. Snaproute is one company mentioned earlier that has been developing solutions in this space. There are existing OEMs who are disaggregating their solutions, allowing the network operating system to run on third party hardware.  

Today, Metaswitch and IP Infusion are 2 examples of companies selling control and management plane capabilities on top of third party network operating systems. An example of the evolution occurring in this space IP Infusion. It has a network operating system for white box called OcNOS, Open Compute Network Operating System. It has multiple vendor product support and covers popular switching and routing protocols. The question is not whether a new ecosystem will emerge to support white box designs – it already has. The questions are really about the following areas:

  1. How quickly can it mature to implement all the requirements that a service provider needs, such as scale, reliability, tiered support, inventory management, maintenance, patching, software image management, acceptance testing, etc.?
  2. How quickly will the service providers adopt solutions based on this new ecosystem and are they comfortable doing so?

There is a bit of a chicken and the egg problem here, which affects the timing for different service providers, based on their comfort level.

Early adopters are well down this path. AT&T is one of those earlier adopters. Timing questions aside, there is no doubt about the eventual direction for the industry and the emergence of white box as a major design element in new SDN networks for service providers.

This shift to white box, brought on by the availability of merchant silicon that satisfies service provider needs, by hardware designs from reliable ODMs, and by the availability of the network operating system and protocols to complete the solution. It signals a new direction and way service providers will design their networks going forward.

The existing OEM suppliers can participate in this new ecosystem. Smart OEMs recognize this trend and are ready to be a part of it. Some have already started by disaggregating their existing solutions and by providing pieces into this new white box ecosystem.

Just as in the web scale industry, initiated by the need for open interfaces to collect data that drives automation, white box and its new ecosystem are finding a home in the telecom industry. AT&T is looking at options in the industry where community-based work in this area could take place.

We will publish a whitepaper in the coming weeks on open architectures for white box network operating systems. Thought leadership is necessary for success. We will be open about our direction and efforts in this area, and we are seeing early indicators of progress that are encouraging.

The participants in this new ecosystem grow bigger and stronger every day. The interfaces and components of the ecosystem become clearer every day. The decision to shift to this new direction is getting easier, and the benefits of adopting designs based on the new ecosystem are becoming greater. In short, network designs based on white box are getting easier to scale every day.