• 05/09/2016
    6:30 AM
    Calvin Chai, Head of Product Marketing, Pica8
  • Calvin Chai, Head of Product Marketing, Pica8
  • Commentary
  • Connect Directly
  • Rating: 
    1 vote
    Vote up!
    Vote down!

Network Disaggregation: Opening The Last Black Box

Switch ASICs must be opened up to provide real networking flexibility.

Most people think of network disaggregation as separating hardware from software, but the story goes deeper than that. While hardware and software separation are a big part of the SDN concept, there is also disaggregation of network switch ASICs. There are five switch ASIC manufacturers in the market and each product has different strengths and weaknesses. These ASICs represent the final “black box” that must be opened before we can truly achieve disaggregation.

The concept of software-defined networking is often described as  based on open, interoperable systems that can be customized for each application, and that deliver services through policy-driven architecture. With a policy-driven network, for example, service providers can implement self-service customer portals where customers can dial up the desired amount of bandwidth.

One way to implement  SDN is by  unlocking several “black boxes” that previously limited networking to a one-size-fits-all approach obtained from vendors like Arista, Cisco and Juniper. Opening each “black box” results in giving customers more choice about how they tune the network for their specific applications.


The first “black box” was the hardware. Once available only from big-name hardware vendors, servers and switches became available directly from the same original design manufacturers (ODMs) who supplied the big vendors. Suddenly vendors like Accton, Agema, and Quanta began offering “white box” servers and switches with lower prices.

The second “black box” was the network data and control planes. SDN separates data plane and control plane functions with OpenFlow and external SDN controllers. This separation gives customers a choice of SDN controllers for policy-driven networking.

The third “black box” was the network operating system (NOS). Once proprietary systems that were supplied only by the big networking vendors, these NOS products are now offered by software vendors like Big Switch, Cumulus, and Pica8. The NOS 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 to port a NOS onto that same piece of metal. This is why so-called white-box SDN vendors either sell the complete switch and OS solution or provide a list of pre-qualified switches so you can directly buy the hardware.

The fourth “black box” is the switch ASIC. There are five major suppliers of switch ASICs -- Broadcom, Cavium, Intel/Fulcrum, Marvell and Mellanox -- and each  optimizes its ASIC for different desired characteristics. For example, an ASIC optimized for the data center would offer VXLAN support, while an ASIC optimized for the ability to handle millions of flows would appeal to service providers with edge networking applications.

The choice of ASIC is important because different ASICs deliver different features. But the NOS must be able to interact with any ASIC in order to offer customers true flexibility. NOS products achieve this with mechanisms like Table Type Patterns (TTP), a framework driven by the Open Networking Foundation and supported by over 100 companies.

With TTP, network engineers and operators can now implement OpenFlow at greater scale – in some cases, up to two million flows (a 1,000x increase from previous methodologies) – while still using standard, white-box hardware. TTP does this by allowing the NOS to access all of the ASIC’s memory tables  --VLAN, MAC, and IP along with ternary content-addressable memory (TCAM) tables -- to store flow forwarding information. Prior to the advent of TTP, OpenFlow scalability was limited by the size of the TCAM, since only the TCAM could be used for storing flow forwarding information. OpenFlow versions 1.3 and 1.4 support TTP.

By opening up the ASIC, NOS products allow network engineers to choose any switch as the basis of a custom networking solution. And customization is the real point of network disaggregation. Rather than investing in a “one size fits all” network, customers can build their networks to order using SDN, white-box switches, and a selection of switch ASICs.

Calvin Chai is the head of product marketing for Pica8, a supplier of open systems for software-defined networking. He is responsible for the GTM strategy and execution for the Pica8 portfolio of open switching systems and software. Prior to Pica8, Calvin held numerous leadership roles in product, technical, solution, and corporate marketing. Most recently, he led the cloud product marketing team at Juniper Networks where he was responsible for the marketing strategy focused on the cloud and data center markets.  rior to Juniper, Calvin spent 10 years at Cisco focused on various technology initiatives including integrated security, policy, and identity management solutions. Calvin holds a BS degree in computer science and engineering from the University of California at Berkeley.


Good first step, but there's more to this issue

I'd like to encourage and support Calvin's thesis in this article, not be seen arguing with it. At the same time there's a larger picture I think is worth exploring.

In the server business, incidental to disaggregation of software from hardware, a single CPU architecture ended up dominating. I have long suspected that a single switch pipeline (with all its limits and peculiarities, just as the dominant CPU architecture has its limits and peculiarities), complemented by software (DPDK) based switching, will similarly be an enabler of disaggregation in data center network switches.

That having been said, it is interesting to watch P4 emerge from academia, with the thesis that software configurable packet processing pipelines are superior to today's hardwired pipelines. Should we focus our energy on describing the tables in the switches to software, or in software telling the switches how to configure their tables? It will be years before the market speaks on this topic.

(speaking for self, works for HPE)