Wednesday, April 3, 2013

What can't OpenFlow do?

Today's talks about software-defined networking have led to some lively hallway discussions about OpenFlow and the research it jumpstarts, by separating the control and data planes of a router or switch and exposing a well-defined interface between them.

At the risk of making this an all-SDN blog, I thought it would be instructive to try to understand OpenFlow by the light of what it isn't. That is: What kinds of practical networking policies can't OpenFlow currently express?

My understanding is that this list would include:
  • RED, BLUE, or CoDel
  • ensuring that contending endpoints or flows share the capacity of a congested link equally (e.g. with per-user queueing)
  • serving as an endpoint for an IPIP or IPsec tunnel or VPN
  • specifying that Skype's UDP datagrams should jump to the front of the line waiting to egress on a port
  • limiting queue lengths to control "bufferbloat"
  • ...?
This is not my area, and I may be wrong here. In any event I don't mean to suggest that OpenFlow is somehow inappropriate for its actual intended uses.

But I do wonder whether the phrase "software-defined networking" has turned out to be a bit broad compared with what the practitioners mean when they use that term.