FAWG Chair Curt Beckmann provides a high level perspective on what OpenFlow® TTPs are about, following the recent publishing of a new specification by the group.
OpenFlow® controllers have been a part of the SDN lexicon from the beginning. Deploying software-defined networks in virtualized data centers has made us familiar with the notion of orchestration. Controllers deal with a single functional domain, say, networking or storage; orchestration coordinates across multiple domains, just as a musical orchestra includes a variety of types of instruments.
The origins of musical orchestras have interesting parallels for the development IT orchestras. Humans have been making music for millennia, but orchestras are a relatively recent phenomenon. Before orchestras, musical production was “vertical”; local groups typically performed pieces that were conceived and arranged within the group, taking into consideration the unique capabilities of the musicians and their instruments. Instruments, orchestral make-up, musical notation schemes, and even tonal systems varied significantly, even as late as Bach’s Well-Tempered Clavier. Orchestras enabled “horizontal” musical solutions; a symphony composed in one place could be replicated by geographically distant groups. As the common orchestral framework spread, musical compositions and performers could travel, offering “portability,” an early musical “plug and play.”
SDN is still young. Many networking devices support OpenFlow® 1.0, but the control capabilities of that specification are limited. OpenFlow® 1.3 is more expressive, but device support for it is less consistent. Network devices and deployments vary significantly now, just as instruments and orchestral make-up varied for a long period. (Consider the Octobass, which is neither an SNL spoof, nor a Marvel supervillain.)
The networking industry has many standardized abstractions, like 802.1Q and IPv4. Other abstractions, such as ACLs, PBR, and VRFs, vary widely. Developing broadly applicable SDN solutions is tricky in such an unpredictable context. Trickiness impedes adoption.
This trickiness is not some aspect of the OpenFlow® protocol; the challenge is inherent in the development of SDN. We need a highly expressive language to control a broad range of capabilities, but in the near (and even medium) term, not all devices will perform all functions. So how does an architect know what to expect from the devices in a network? How does a device developer understand what features will be required for the coming killer SDN apps? How does a buyer choose products?
Musical orchestras benefited from clarifying the expected capabilities of different instruments. SDN needs a similar scheme for clarifying what a networking device is expected to do in a given role. This need to clarify expectations and interoperability prompted the Forwarding Abstraction Working Group’s (FAWG’s) formation and its development of the Table Type Pattern (TTP) framework. The TTP framework enables an architect to describe a set of device functionality (a subset of the full OpenFlow® set) which will be controlled using OpenFlow. The (optional) usage of a TTP clarifies two things: what forwarding capabilities will be used in a given context, and how those capabilities can be controlled via OpenFlow.
TTPs are parallel in some ways to added information that composers include in a musical score. We can view the notes on the scale as similar to the run-time control messages of the OpenFlow® Switch protocol. But musical scores have more information than just notes, including key signature, time signature, the instrument intended to play the notes, etc. This added information is less dynamic than the notes, and yet vital to the success of the composer/orchestra collaborative production. TTPs are similarly complementary information to the OpenFlow® Switch messages.
The TTP specification provides a foundation on which to build more scalable and interoperable SDN networks. Groups inside and outside the ONF have already begun incorporating TTPs into their efforts. You can learn more about TTPs and how they work by reading the TTP FAQ and the OF-TTP specification itself, which includes an overview of the motivations behind the development of TTPs.
If, like me, you believe in the power of the SDN vision, I invite you to explore the TTP framework. You will learn how TTPs can provide an “instrumental” structure and language for building SDN interoperability without inhibiting flexibility. I look forward to working with you to produce new and moving network symphonies!
- Curt Beckmann, EMEA CTO at Brocade and ONF Forwarding Abstractions Working Group Chair
