After my last post on extracting useful information from the Broadcom TTP file, I thought it would be interesting to write a validator and linter for TTPs. As far as I can tell, there are no public TTP validators based on ONF’s OpenFlow Table Type Patterns specification. A TTP is essentially a JSON file that defines what specific hardware can handle in regards to being controlled by an OpenFlow 1.3+ controller. Broadcom released a TTP for their EA version OF-DPA2.0 and is linked to in our resources page.
To download LinTTP for free, visit its product page and click “download”. It is provided in the MIT License and is provided in the hope that it will be useful. The README.md file provides a detailed example and usage information.
As mentioned previously, The Broadcom OF-DPA 2.0 TTP file (v18.104.22.168) does not actually conform to the specification and looks to either be generated by hand or by script without much regard to automated processing. If a controller were to try to parse the TTP, it would not be able to get the information needed to generate the flows required to pass traffic. After all, it is an early access document and I don’t think it was designed to be used that way at the start. However, eventually these documents will need to be produced and conform to the TTP specification so the vision of controllers determining the flow mods required to pass traffic in a certain manner can become a reality. Right now, we developers are forced to write flows statically or, at best, write code that generates flows based on certain assumptions we as developers pick up through experimentation or hunting through hundreds (sometimes thousands) of pages of documentation. Mistakes will be made if this continues. The promise of multiple vendors producing valid TTPs leads to a world where we can teach our controllers how to write the flows itself based on what the hardware switches say they can manage. These TTPs can also help facilitate better and automated testing across diverse environments, both in software and hardware. And to promote all this, I have started my own validator and linter: LinTTP.
LinTTP is still in early stages, but is functional. It currently finds several errors in the example TTP file provided in the specification itself with references to section and page numbers in the specification where the restrictions are defined. I learned a lot about Table Type Patterns in the past few days writing this and I think it is a great exercise for anyone who really wants to know exactly how TTPs work and why they are specified as they are. It also brought up several questions, which I comment in the code, about what the specification is trying to say. The spec is quite vague in some areas and open to interpretation, or require looking through the example to try to figure out what the original authors meant. In some cases, I had to look at recent examples provided on the ONF’s github repository on what meta-member types are valid.