Conversations are swirling throughout the tech industry about whether white box switches are disrupting the networking industry, similarly to how white box manufacturers helped commoditize the server industry. If this recent InfoWorld article, is not enough to persuade you, consider that even John Chambers himself has recently chimed in on the threat of white boxes eroding Cisco’s margins.
The idea of white box switching from a Pica8 perspective is to help create an operating abstraction between the “metal” (in our case white box switches from original device manufacturers, or ODMs) and the network operating system (OS) itself. When that’s created, you have a degree of OS portability.
In a typical first meeting with a prospect, we frequently get asked if they can port a version of our OS on their existing Cisco switches. At first blush, it makes sense but let’s examine the three key issues that need to be addressed to truly make an OS compatible with a “bare metal” switch.
The network OS must comply with three key component areas within the device: the CPU and the motherboard (or the BSP), “U-Boot” (or universal boot loader), and the ASIC’s APIs. All three collectively need to be matched to the network OS in order for you to port your OS onto that same piece of metal. This is why all the so-called white box, software defined networking (SDN) vendors either sell the complete switch and OS solution or provide a list of pre-qualified devices so you can directly buy the hardware. Both paths deliver the same solution. I will mainly focus on these three component areas so you can assess the level of portability of your network OS.
The CPU and the motherboard – Thanks to PCs and the server market, making your OS work with any CPU is the easiest part of the puzzle to solve. Any modern Linux OS will have the needed drivers and kernel support for all common CPUs. You can assume this is not a problem, but the motherboard consists of other chips than the CPU. You need to make sure you have full access to the driver code of all chips to ensure that complete functionality can be accessed through the new OS. This need is new and particularly topical for Ethernet switches because servers don’t have U-Boot functionality–they have BIOS.
The universal boot loader (U-Boot) – As part of a modern Linux OS, the U-Boot is essential in both white box servers (think Pixie Boot) and white box switches. This Linux OS that holds all the details on the shell of the box itself like the fans, lights and USB ports as examples that map directly to the shell or actual box. As part of Facebook’s push toward an open switch specification augmenting the Open Compute Project (OCP) for servers, a common U-Boot loader for future switching hardware is being discussed. Other than this initiative, U-Boot loaders are hidden from users and are one of the reasons you must have pre-qualified white boxes. Every manufacturer has a different U-Boot loader; and even within product families of the same vendor, the U-Boot code could be different.
The ASIC – Every white box or legacy switch has an ASIC in it. The ASIC provides performance scaling and is key to how switching helps build a high-bandwidth network. Whether you leverage merchant silicon (Broadcom, Intel, Marvell, Mellanox), or your own ASICs, you need to have a means to connect the chip to your software stack. That is through the ASIC programming interface or software development kit (SDK). For merchant silicon, you sign a license with that vendor, while in-house ASICs are internally developed. Either way, you can see the barrier here. As a user, you need to have access to this information, either through the OS vendor telling you they are compatible with the ASIC, or in our example above, the existing vendor has to allow you to see this API in order for the OS to sit on a legacy switch.
So in summary, leveraging a modern Linux distribution will take care of the CPU; however, you have to confirm your OS works with the U-Boot code on your switch and the ASICs. This is why porting even the most portable network OS to Cisco, for example, is not easy (putting aside any warranty or legal issues). Cisco would also have to tell you what their ASIC API looks like and give you access to their U-Boot code.
So can portable network operating systems “retread” all those old switches out there? It could happen. I think you will see more opening up of the boundary between the network OS and the box. Universal portability, not so much, but selective hardware compatibility, yes!