The data center industry has embraced hardware/software disaggregation promoted by Open Compute Project (OCP) in servers and switches. It brings benefits of cost, flexibility and innovation. OCP has now started a working group called Campus, Branch and Wireless (CBW) to extend disaggregation concept to enterprise networking. For additional details on OCP/CBW whitebox WLAN AP, see this #wlpc 2017 video presentation by @CHemantC. Mojo Networks has been an active contributor to the CBW group. At the recently concluded Open Compute Summit in Santa Clara, we demonstrated open install of Mojo WLAN software on the latest Qualcomm 802.11ac Wave 2 AP platforms manufactured by 3 different hardware vendors (ODMs).
The key to whitebox APs is OCP’s Open Network Install Environment (ONIE) specification. Let’s take a look at what it takes to adapt traditional enterprise AP software to ONIE compliant software stack. At a high level, an ONIE compliant system has the following main components:
- Boot Loader: This is typically u-boot on AP platforms.
- ONIE Partition: This consists of the Linux kernel, system and networking utilities and discovery scripts to download network OS.
- Network OS (NOS) Partition: This is a WLAN software image.
The key stages in the system’s life cycle are as follows :
- Initially, during manufacturing, the system is programmed with Boot Loader and ONIE Partition. This is done by AP hardware vendor.
- While the system boots from the ONIE Partition,
- It can accept input about the location of the NOS image to be installed
- ONIE will download and install the NOS partition image
- After successful NOS installation, ONIE will configure system’s boot parameters to boot from the NOS partition
- System will reboot and now boot into the NOS partition.
- The system will now continue to boot into the NOS partition and operate as AP.
- From the NOS partition, system’s boot parameters can be modified at any point to boot back from ONIE partition. System will reboot into ONIE partition and is essentially back at step 2. At this stage, it is possible to uninstall, replace or upgrade the existing NOS image.
Thus the ONIE based dual booting capability of the system gives complete freedom to end user to install NOS image of their choice. Therefore, the first requirement for developing an ONIE compliant system is to create a dual partition flash layout for the platform. The ONIE source repository has several example platforms that are a great reference while adding a new platform to the build system. The required system and networking utilities as well as NOS discovery scripts are already part of the ONIE source.
Click here to compare flash partition layout of traditional blackbox and ONIE compliant whitebox APs.
For mainstream adoption of whitebox APs there are a few more things that need to be addressed such as :
- Secure Boot and Install: While installing a NOS from the ONIE partition, there needs to be a way to verify authenticity and integrity of the NOS.
- Robust Recovery and Repair: The dual boot process described above needs to gracefully deal with network faults and power interruptions. This is particularly imporant when large number of distributed APs perform NOS installation or NOS switchover.
- Regulatory Compliance: The NOS image on an AP controls RF transmit power and operating channels. In a whitebox AP ecosystem, since there is flexibility to install different NOS images, mechanisms are required to ensure that the installed NOS image meets the necessary regulatory requirements.
These issues are being discussed and debated in OCP’s CBW working group. Interested NOS vendors, ODMs, silicon providers and end customers are most welcome to join the ongoing debate and contribute their ideas. We’ll be sharing technical updates for the benefit of all. Stay tuned!