White Box Switching: Goodbye Trident II, Hello Cavium XPliant

Original Design Manufacturers (ODMs) that produce incumbent profit busting white box switching technology could soon be releasing the next wave of programmable networking based on technology from a silicon company best known for it’s encryption products. Cavium have released the XPliant chipset which it acquired from a $90m purchase earlier this year. This chipset comes in four flavours varying from 880 Gbps to 3.2 Tbps. This results in devices having 128×25 Gbps switching lanes allowing switches with 32x100GbE, 64x 50/40GbE, or 128x 25/10GbE ports in a single device. The highest speed Cavium device is currently twice the speed of the next highest merchant silicon offering, however merchant vendors will catch up with the speed aspect before too long. The important part here to remember is this chipset is programmable and is touted to be released with support for Generic Network Virtualisation Encapsulation (GENEVE) out of the box, along with a “simulator” for product designers to test their code against. All designed to increase the speed to market and decrease delay.

Let’s take an ODM switch from the likes of Accton that is currently based on the venerable Trident II chipset. Current merchant silicon chipsets limit the features to those ‘baked in’ when the silicon goes through the patterning sub-production process. An ODM device with the XPliant chipset will not have this limitation and can receive protocol updates over the wire. In addition, the refresh cycles by the vendor may only really cover memory and speed as opposed to baking in new protocols. This could result in an silicon eco-system shift to R&D in to cool memory technology (see Cisco acquisition of Memoir-systems and even higher speeds instead of baking in protocols. You want some weird mess of a protocol? Knock yourself out! Designers can roll out protocol bug fixes quicker which also means fewer blown bucks on ‘errata’.

Take something like Cumulus Linux. It could have a dedicated driver for this chipset which might even mean eventually, you, the network engineer could write your own protocol set. Neat eh? One last thing, note that this is not an FPGA. Information on the programmability aspect is limited at the moment (sadly). One thing I am interested to learn is what the pipelining looks like? We’ve been hindered by a chipsets ability to recirculate packets without pushing it back through the forwarding pipeline. This has meant that the Nexus 9K devices in the spine in NX-OS mode are (still are I think?) incapable of VXLAN routing. Do not confuse VXLAN routing with VXLAN bridging. VXLAN routing is the concept of routing Layer 3 IP packets within a VXLAN segment to another IP subnet in a different VXLAN segment, not the actual forwarding of encapsulated packets or bridging between a VLAN and VXLAN segment. Most chipsets however can handle a single lookup and encapsulation for VXLAN bridging.

Although this isn’t a new concept (look at the Juniper EX9200 and the Cisco Catalyst 3850 with the unified access data plane or UADP) and I’ll be watching this space carefully. Software especially when coupled with Intel’s Data Plane Development Kit (DPDK) is fast, but dedicated hardware will always be quicker.

Dave

Say thanks and buy me a coffee!

• Tags:
• Categories: