Welcome!

If everyone is thinking the same, someone isn't thinking

Lori MacVittie

Subscribe to Lori MacVittie: eMailAlertsEmail Alerts
Get Lori MacVittie via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Cloud Computing, Telecom Innovation, F5 Networks, DevOps for Business Application Services, SDN Journal, DevOps Journal

Blog Feed Post

The Programmable Data Path: It's Not Just Extract and Act

Data path elements that are programmable imply the ability to execute business and operational logic

Like most terms associated with any technology in the beginning of the hype cycle, programmability is being used and abused to mean a variety of different capabilities. It's important to understand what people mean when they say "programmability" because it ultimately impacts the ways in which you can use it.

Many application-driven solutions claim programmability as a key characteristic and, by extension, a benefit. The benefit, of course, is being able to customize the behavior of the solution to fit just about any possible solution. Zero-day exploit? Check. API versioning change? Check. Application needs the actual IP address of every client? Check. There are too many possibilities to list because the point of programmability is that you can make a programmable "X" do anything.

For the past decade or so, however, the term "programmability" has been used to describe two very different kinds of anything. On the one hand, there's programmability in the classic sense: execution of logic. On the other hand, there's programmability in a more limited sense: extract and act.

The difference may, at first, seem subtle or even pedantic. The ability to extract data, evaluate it, and act on it certainly seems on the surface to be execution of logic. And it is - at least on very rudimentary level. The problem is that "extract and act" systems tend to proscribe what it is you can extract as well a what actions you can take.

For example, a modern switch is programmable when using an "extract and act" definition. A switch can extract data from an IP packet such as source and destination IP and then choose to forward or deny based on policy. Many L4-7 devices, too, can accomplish this feat at higher layers of the stack, enabling "extract and act" capabilities against HTTP headers as well as TCP and IP variables.

But no one has ever referred to a switch as programmable because it can "extract and act". Such capability is a very limited subset of programmability, and is more accurately described as configurable, not programmable.

Programmability implies a more free-form definition and execution of logic. Logic that enables not only extraction and action, but transformation and collaboration. Programmability enables extensibility; the creation of new services designed to meet a specific operational or business need not currently addressed by available solutions. Programmability doesn't limit you to this HTTP header or that TCP option. Programmability is imagination and innovation and comes without such highly limiting constraints.

SDN architectures today speak in broad terms about programmability but the applicability of that characteristic pertains only to the controller, not the data path. The northbound API, on which many dreams and hopes for the success of SDN are currently laid, gives SDN controllers the right to call itself "programmable". The northbound API enables extensibility, that is the ability of the system to extend its features and functions and capabilities programmatically. Using the northbound API, anyone (ostensibly) can extend how SDN controllers make decisions and, ultimately, how traffic is routed through the network.

reduced-speed-aheadBut that programmability does not necessarily extend to the data path. The data path, comprising the switches that form the network fabric, still operate under the constraints of an "extract and act" model and it can only extract from data available which, at this time, means TCP and below in the network stack. Extending the SDN controller's capabilities does not change what the switches it controls (and thus the data path) can do. The SDN data path is not truly programmable. Oh, it could be, and the notion of extending a controller with applications via the oft-mentioned northbound API would certainly allow this. But suddenly we've inserted software running on commodity hardware with all the limitations on scale and capacity that implies, into the data path. It's the 25 mile an hour zone on a US highway that runs through a small Midwest town. It can easily become a bottleneck.

That's not going to be acceptable in the long run, because anything that impedes the speed of the data path ultimately impacts the responsiveness of the application and that, as well all know, is unacceptable.

The SDN data path will never truly be programmable unless programmable data path elements are inserted and enabled with the ability execute actually logic; logic that enables modern application architectures to be implemented with relative ease without requiring you to "reduce speed ahead."

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.