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"
- ...?
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.
What I found is that OpenFlow model (match and action) cannot handle the policies where the action of a rule depends on the action on other rules. For example, in rate-limiting policies where we want to share remaining capacity of a link in a fair manner, we need to know what happened to the other flows that may have a separate rule.
ReplyDeleteBesides, the counter model of the OpenFlow may not be enough for measurement tasks especially when the latency between the controller and the switches is so large that it cannot adjust rules so often. Sketches may be an option to replace counters.
Note that OpenFlow is somewhat of a moving target, both in terms of the spec (now at version 1.3.1, which I think supports some of the things that Keith mentions), and in terms of research proposals for further evolution.
ReplyDelete