Building a network operating system (NOS) is a major undertaking for any organization, requiring significant amounts of time and money to complete.  Until recently, creating a NOS was the preserve of OEMs and an essential part of their networking solutions. In the last few years, a few new disaggregated NOS suppliers have emerged providing independent NOS solutions for white box hardware. A variety of open source NOSs have also been created, affording operators with a low-cost option for network solutions but these offerings are mostly limited to today's data center use cases.

The emergence of cheap but powerful white box and brite box hardware, coupled with a third-party network operating system, represents a challenge for traditional original equipment manufacturers (OEMs) who struggle to compete on price and openness.  However, this also provides an opportunity for OEMs to create portable network operating systems which target more complex use cases and work on either proprietary or white box hardware.

Why build a NOS?

For many years, data center operators have used disaggregation and open source software to drive down costs. They have reduced capex by employing cheaper hardware and software, and decreased opex with automation, orchestration and telemetry applications. This trend started with compute servers and more recently has moved to network devices in the data center – in particular, Top of Rack and leaf/spine switches.

Until now, these savings have been unavailable to traditional service providers. The increasingly complex requirements mean their networks are still dominated by monolithic devices using proprietary hardware and software from a select number of larger players and a host of smaller OEMs.

The cost of building and supporting emerging network infrastructure and applications, however, will be greater than ever before, so service providers must take this opportunity to look for innovative ways to achieve even more savings. Replacing monolithic devices with white box hardware and disaggregated software is one of the main ways they will use to achieve that.

Suppliers of network solutions can take advantage of this opportunity by building a network operating system that support their powerful proprietary hardware and white box alternatives. By also exposing modern open interfaces such as NETCONF, the NOS can be easily integrated with custom and third-party applications in customer networks. Moreover, such a NOS can be easily upgraded with new capabilities and ported to new platforms, helping to address new use cases and remain at the cutting edge of this fast-moving industry.

Open Source vs commercial solutions

20 years ago, the standard OEM approach was to create the necessary function from scratch using an in-house software development team building on top of a vanilla Linux distribution. Due to the immense cost of implementing complex protocols such as OSPF, BGP and MPLS, however, this approach is now almost never taken. Today, the base of any NOS is typically Open Networking Linux (ONL), which (as the name suggests) is open source and freely available, meaning that the investment required to create an entirely new base OS to replace Linux is unlikely to be justified.

For the management and protocol software, however, there are two high-level options. Choosing the right one is important, because once you’ve shipped a first version of a product, making significant changes to the user experience can be disastrous.

Open Source

There are open source protocol implementations (such as Quagga, BIRD, and FRR) and open source management agents such as OpenYuma. Starting from one of these has advantages over building your own, particularly in terms of time-to-market and short-term cost:

• The implementations already have some level of maturity - fewer bugs, better interoperability.
• You can hire engineers who already understand them.
• You may be able to take advantage of new features that the community contributes over time.

However, there are downsides, particularly for protocol software:

• Companies rarely contribute back to the community, so the fact that other vendors have deployed products based on open source doesn’t mean you’ll have an easy time doing the same.
• Feature support tends to be minimal for the same reason.
• They are low in scalability, availability, supportability and general quality.
• Without sufficient adoption and commercial backing, the community moves on and you can find yourself locked into a dead-end product that ends up being as expensive as writing it yourself.

Open source can work for a tightly scoped deployment scenario, but it is unlikely to pay off (versus a commercial alternative) for a product you expect to be selling and supporting for many years and want to apply to future platforms.

Commercial

The commercial protocol software model is that a vendor implements a stack such as BGP or MPLS and then licenses the source code to many NOS implementers. The result is that the software vendor has enough commercial return to continue to significantly invest in the protocol product (in terms of features and quality), while each NOS implementer only pays a fraction of that overall development cost.

As a result, commercial software tends to be much higher in quality and functionality, and the vendor typically has a strong roadmap for the newest features.

It also typically comes with a support and maintenance contract for fixes and small features, which costs much less than you would have to pay your own engineers to maintain an open source-based solution.

In addition, when building either highly resilient platforms (such as a chassis-based system with multiple process cards) or high-function platforms (such as VPN services over MPLS with sub-50ms packet loss on link failure), commercial software is often the only viable choice - re-engineering open source solutions to support these use cases is incredibly expensive.

The upfront cost of commercial software may of course be a reason to prefer other approaches. However, some vendors now offer subscription-based or revenue-share agreements, making it more attractive.

The Metaswitch NOS Cookbook

Until now, creators of network operating systems -- including system vendors --  had little choice but to build their own Linux distribution from scratch, including interfaces to all of the hardware components such as fans and LEDs. Metaswitch has now changed that dynamic, dramatically reducing the cost and time-to-market when delivering new products and platforms. Our new NOS cookbook provides step-by-step instructions on how an OEM can quickly and cost-effectively build a modern Network Operating System by employing a combination of Open Compute Project (OCP) technologies, open source software and commercial solutions, where appropriate.

You can download the metaswitch NoS cookbook today at www.metaswitch.com/cookbook