Software-Defined Hardware Forwarding Pipeline on HP Switches
Writing OpenFlow controllers that interact with physical hardware is harder than most people think. Apart from developing a distributed system (which is hard in itself), you have to deal with limitations of hardware forwarding pipelines, differences in forwarding hardware, imprecise abstractions (most vendors still support single OpenFlow table per switch), and resulting bloated flow tables.
Now imagine you could reprogram the hardware forwarding pipeline with OpenFlow. That’s exactly what you can do on the next-generation switches from HP. For more details listen to the Episode 37 of Software Gone Wild with Chris Young and Craig Mills from HP. The podcast was recorded during Interop Las Vegas 2015, so you’ll be able to “enjoy” the background noise of the show floor.
Note: I was wrong. Controller-initiated reprogramming of the forwarding pipeline is part of OpenFlow standard (the table description structures are read-write, not read-only as I claimed in the podcast).
BTW, if the topics in the podcast sound like Latin to you, and you’d really like to grok them, consider watching the OpenFlow Deep Dive webinar.
HP/H3C´s Comware based 5930 uses Broadcom´s Trident II chipsets with one small TCAM => single OpenFlow table per switch.
HP Procurve OS based HP 5400R (V3) switches use HP´s own "Provision ASICs" => That´s the one with programmable hardware forwarding Pipeline.
with write transactions on tables of switches (== non standard Openflow 1.3) Therefore I need to purchase HP´s SDN controller...
While it's true that O/F allows the controller to "write" to the switch the table-Features, I know of no HW switch that supports it, and have not heard of a single case where this was successfully used. It may exist - but may be under NDA. I regularly attend ONF meetings where this would have been big news.
(Even with SW switches, or NPU-based switches, Where this could be supported, assuming some way to handle resource allocation for each asked-for data-plane configuration - if this exists, it is not widely publicized)
Even the READ part of this is hard with ASIC-based switches. OpenFlow allows them to implement a different subset of features in each table, and to select which function will be done in which table. Different vendors. or even different switch models of the same vendor, even if they all use the same ASIC or ASIC family, may (usually are) different in details.
On the other hand, the controller must know EXACTLY which table does what. if you write an application, you must find a way to map your requirements on the exact combination of which table does what in which switch model - this can quickly get to an astronomical # of possible permutations, so you tend to use the minimum denominator, or go single-vendor, or both.
No full solution (that I know of) exists for this, but some mitigations are TTP's and Switch-profiles, and PO4 used to promise to bypass this by having a paradigm of controller DEFINES the data-plane, switch implements it, then controller can use what it has just defined. how this will work in practice - We'll see.