In the world of customer premises equipment (CPE), the white-box is a new idea. It should then come as no surprise that misconceptions among operators and CSPs about what constitutes the white-box CPE are common. Here are four of the most prevalent.
Myth #1: The white-box CPE is just commodity hardware.
No. The software-hosting platform is the most important part! Google and Apple have succeeded with smart phones because they created killer platforms, carefully designed to provide a secure environment ready for third party developers to exploit, which enabled their apps base to proliferate. The white-box CPE is no different. Don’t get me wrong, it is still all about using commodity hardware, but this is just the tip of the iceberg. It’s enabling potential stems from the software platform that controls the hardware, not from the hardware itself.
The same goes for the network functions running on the white-box CPE. They need to be installed, chained, activated, run, provisioned, monitored, charged and, of course, done so in a secure manner with maximum efficiency and predictability.
We’re not talking about any old software here, either. This is highly specialist, instance-specific software but unlike smartphones the functions are often dependent on each other. There are lots of open-source components that can carry out each of these tasks individually, but they also need to be integrated, managed with homogeneous, standardized APIs and provided with pre-packaged, documented use cases to facilitate their integration. We often see service providers adopting a DIY approach. But this only lasts until they realize the extent of work and the depth of know-how required to assemble all these pieces together. Building a demonstrator is one thing; warrantying the operational lifecycle over the lifetime of a service is another.
Myth #2: White-box CPEs are for everyone.
The whole idea of white-box CPEs is to foster the ability to take VNFs from multiple vendors and have the freedom to mix-and-match them according to the service provider’s desired functions, price and brand.
This is all good ‘on paper’. The reality, however, is different. Just like when specifying additional options on a car, the bill soon adds up. In fact, imagine being able to walk into a VW dealer and demand options from BMW, Mercedes, Honda and Ford. Welcome to the world of the white-box CPE!
Large enterprise can afford it because, right now, they are buying single-use network appliances and stacking them up in the customer’s premises. The white-box CPE’s promise of appliance consolidation is so great that the economics allow it to be expensive.
The business case for the SMB market is trickier, where price is under far greater scrutiny and customers require simple and replicable solutions. If they can find the right package at the right price (with equal functions and security), it could indeed come in the form of a white-box CPE, but it could just as easily be something else. And that’s precisely the problem right now: in terms of flexibility, the white-box CPE may beat purpose-designed CPEs but at this moment, in this market segment, they can’t win on price.
Myth #3: VNF Modularity is Always Great
Modularity is always thought of as good practice. But consider this: if a function is split into two VNFs, it must be chained somehow. There is also likely to be some functional overlap. Splitting the router and firewall functions, for example, will most likely result in the need to run the routing function twice.
The SMB market, with its more challenging economic conditions, is likely to need resource-optimized network functions pre-packaged together in order to bring the solution to market at an acceptable price point. Leaving some resources on the white-box CPE redundant to enable flexibility in future VNF deployment is not an option here; it will blow the budget. This means, for now at least, that jointly architected components are the order of the day.
Myth #4: All white-box CPEs are OPEN
Not all white-box CPEs are created equal.
Again, on paper, white-box CPEs should provide the openness to source VNFs from multiple vendors. The idea implies an open, componentized software design. So, no vendor lock-in, right? Wrong. I see new entrants claiming to have white-box CPEs, but on closer inspection their software platform is revealed to be far from open. Third party VNFs are not supported. Sometimes the only documented API is the northbound interface of their management system. In other cases, the appliance uses some sort of OpenFlow, but such that it can’t be directly exploited.
Although some of the design promises of Software-Defined Networking are fulfilled (using off-the-shelf hardware, programmability, API’s), large parts of the solution remain a black-box, which inevitably ends up in the pitfall of lock-in, a long way away from the appliance’s original promise.
Despite the myths, however, reality is starting to take shape. Opposing forces in the industry stimulate competition and are shaping the future: off-the-shelf vs dedicated hardware, integrated suites of network functions vs purpose-designed VNFs, different solution costs, etc. Ultimately, end-users will benefit from this profusion of options.
