OpenFlow Table-Type-Patterns and Vendor Hype

Network Computing recently published an article with a promising title “Network Disaggregation: Opening the Last Back Box” and a subtitle I could totally relate to: “switch ASICs must be opened up to provide real networking flexibility.”

The article starts with excited black-box-busting cheerleading describing hardware disaggregation (first black box), centralized control plane (second black box – I disagree but let’s move on) and network operating system (third black box)… and finally identifies the final black box: switch ASICs, where it mysteriously fails to identify the real problem: major ASIC vendors are hiding their documentation from public scrutiny.

Well, the mystery is solved the moment you get to the end of the article – it was written by head of product marketing for Pica8, whose whole product line uses one or another Broadcom ASIC, totally destroying the potential credibility of the article.

And what’s the “solution” proposed by Pica8? OpenFlow Table Type Patterns (TTPs), which are nothing more than templates specifying which forwarding features an OpenFlow switch should support. Now let’s see what supposed superpowers these data models give a switch running on an undocumented ASIC:

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.


An OpenFlow-based switch can do only whatever the underlying hardware can do and whatever the NOS vendor implemented in the OpenFlow agent. If Pica8 claims that their software works better with TTPs they’re just saying that their previous software sucked.

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.

More of the same. Every network operating system could access whatever hardware capabilities of the ASIC… at least as long as the NOS developers had access to hardware documentation (see above) and were willing to read it. Or maybe the author is really trying to say that with Broadcom’s OF-DPA you could finally get the most out of Broadcom hardware without having to read the documentation (or deal with hardware intricacies)?

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. 

Yet another misleading claim. As anyone watching my OpenFlow Deep Dive or Data Center Fabrics webinars knows smart networking vendors (including Arista, Cisco, Dell and HP) used TCAM as well as L2 and L3 forwarding tables to store OpenFlow flows for years.

Finally, the article concludes with:

By opening up the ASIC, NOS products allow network engineers to choose any switch as the basis of a custom networking solution. 

Broadcom ASIC is as closed as it ever was, but at least now we have public APIs that could be used to program certain aspects of it (OF-DPA and OpenNSL), and Intel ASIC is as open as it ever was (but that wouldn’t interest the Pica8 marketing guys because they’re not using Intel ASICs in their products).


  1. Ivan, just read this blog post. While I appreciate your position, I’d like to point out a few items:

    1. Yes, we work with Broadcom, but we’re also working with Cavium, and are in discussions with other switch ASIC vendors. Truth is, we will evaluate any switch ASIC and port to it if the customer demand and use case is there

    2. The whole point about TTP is that it abstracts the forwarding information from the ASIC. This allows us to get scale #’s comparable to the incumbents, but in an open, standards-based way on white box hardware

    3. Final point, our customers love what we are doing with TTP and OpenFlow for precisely the reasons above. It eliminates the lock-in and gives them more flexibility to use OpenFlow in their networks

    We (Pica8) spoke about this topic at ONS earlier this spring. Here's a link and also to another article as well:

    Calvin (the marketing guy) :-)
    1. From my knowledge, Broadcom documentation provides access to ALL resources (tables) in the ASIC therefore if you implement Openflow in your own switches you can access those resources anyway, without needing TTP, so no, TTP does not provide you with access to tables that you otherwise could not, just some more openness.
  2. #2 - Totally disagree, and TTPs have nothing to do scaling and abstracting the forwarding information. Let me copy straight from TTP FAQ:

    "TTPs are "Table Type Patterns" — templates that spell out what OF-Switch protocol features and messages a switch needs to support (and a controller needs to abide by) in a given role (for a given “use case”)."
  3. TTPs facilitate the use of tables that were not used before thus improving scalability.

    Yes, you could say that those tables could still be accessed *somehow*. But I believe the work of abstracting the chip pipeline is better done from the people who made the chip.
    1. "TTPs facilitate the use of tables that were not used before thus improving scalability."

      Absolutely wrong. Multiple tables were part of OpenFlow 1.1 (or vendor extensions in OpenFlow 1.0) and were available for years from multiple vendors including NEC, HP and Cisco.

      Let's stop applying layers of lipstick onto this particular pig.
  4. With out Hype does anything sells now a days? If you look at the Openflow Spec, it introduced even the TLV type format as something that is like a new way to provide flexibility even though it existed for a long time and most of the networking protocols rely on that.

    The OpenFlow 1.2 Switch Specification builds significantly upon previous releases
    in many ways, including these significant improvements:
    • It adds support for IPv6. In addition to the previous support for IPv4, MPLS,
    and L2 headers, OpenFlow 1.2 now supports matching on IPv6 source address,
    destination address, protocol number, traffic class, ICMPv6 type, ICMPv6 code,
    IPv6 neighbor discovery header fields, and IPv6 flow labels.
    • It adds support for extensible matches. By employing a TLV structure, the
    protocol allows far greater flexibility for the treatment of current and future
  5. I would love your thoughts on Reconfigurable Match Action Table (RMT) chips and the ability to use openflow as a steering mechanism just on the edge with some controller with a global view. Lets just picture a multi-layer SDN environment where openflow is used at the edge but something like segment routing for the rest of the specific managed domain. All of this augmented with some sort of AI platform, that takes real time information to steer traffic. This could increase UX and resiliency assuming the ability to model the network appropriately.
    Lets assume some SDN controller with the ability to query some ML mechanism which gets real-time telemetry from the network, and is cognizant of some level of service level objectives defined.
    Ingress flow matched via some defined tuple to some egress label stack augmented with SLO objectives for the flow matched could provide added resiliency, as well as better SLO management across the network. Added benefit of using RMT chips could be to change hashing mechanisms for things like TEID, and insert new headers like NSH for perimeter devices that support NSH but not flow table entries. Just something I was thinking as a good use case for openflow.
    Additionally, if one leveraged P4 programming language for the tables, it could be portable across multiple data plane elements, such as OVS using PISCES, VPP using PVPP, smartNICs assuming ICONICS, etc...
    1. I did a podcast on this topic once:

      The idea is obviously enticing. Is it worth the extra cost? I don't know.
Add comment