Wednesday, April 3, 2013

Is software defined networking really just OpenFlow?

Pyretic's Q&A had an interesting question: Is there anything you can do in OpenFlow that you can't do in Pyretic?

This question digs deeply into Pyretic's capabilities, but we don't have a formal framework to compare the capabilities of different SDN programming models, so any negative answer ("No, they are equally powerful") is hard to justify.

Are we (as a community) missing the opportunity to formally define control plane and data plane functionality, perhaps creating a hierarchy of capabilities and examining the trade-offs in implementing those capabilities? Or are we just excited to have a more powerful leg to stand on (OpenFlow) and using that to create cool systems (e.g., NSDI 2013's first session)?

There is some work questioning the OpenFlow abstraction and providing alternate SDN abstractions (e.g., DevoFlow), but I don't know of any formalism to compare functionality. Am I new to the area and missing something important?
Posted by at

8 comments:

  1. ColinApril 3, 2013 at 5:12 PM

    Is x86 not the ideal packet processing language? There's nothing stopping SDN from pushing Turing-complete programs to edge devices or software middleboxes. Switching devices on the other hand are simply not well-suited to performing complex operations..

    ReplyDelete
  2. Josh LenersApril 3, 2013 at 5:43 PM

    Sure, we are limited by today's hardware capabilities, but we should (and are) pushing hardware vendors to include more functionality (e.g., new features in increasing versions of OpenFlow). I'm wondering if we are pushing these features in an ad hoc manner ("it would be nice to use MPLS"), or if we are thinking formally about increasing expressiveness.

    It's also true that we already have arbitrary packet processing in OpenFlow: just forward all packets to the controller (bad performance).

    ReplyDelete
    Replies
    1. ColinApril 4, 2013 at 1:10 AM

      I'm not sure I agree that we should be add complexity to switches. Wouldn't it be cheaper and simpler to keep the switches dumb? Instead of adding functionality to switches, perform complex packet processing at the edge (preferably in software). Then, slap a label on packets before sending them into the core. Switches in the core then just need to perform label-switching, and the controller configures the label-switched paths according to the network policies.

      As far as I understand, this is how many ISPs run their networks. Does this design miss anything that you could otherwise do with sophisticated switches?

      Related articles:

      http://conferences.sigcomm.org/sigcomm/2012/paper/hotsdn/p85.pdf

      http://networkheresy.com/2011/06/05/what-openflow-is-and-more-importantly-what-its-not/

      http://networkheresy.com/2011/11/17/is-openflowsdn-good-at-forwarding/

      Delete
    2. Josh LenersApril 5, 2013 at 3:24 PM

      I'm not sure I agree that we should add complexity to the switches either :)

      As far as I understand it, you're right about current trends: using MPLS , really dumb switches, and doing a lot of processing at the edge is state of the art. What I'm curious about is: do we have intuition/proof/evidence that using dumb switches is just as powerful as smart switches and what are the trade-offs?

      Delete
    3. ColinApril 7, 2013 at 7:15 PM

      I see. Good question!

      Delete
  3. Keith WinsteinApril 3, 2013 at 5:50 PM

    Josh, I like your post a lot. It seems to me (and I tried to get into this in my SDN post as well) that some Pyretic programs might not be possible to realize efficiently on OpenFlow, because most or all packets would need to be forwarded to the controller as you say.

    I wonder if we can reason about the complexity classes of various software-defined network topologies in this sense; in terms of when the control plane (or switch flow-table capacity) becomes a limiting factor for overall network performance.

    I also wonder whether a reasonable-seeming SDN topology might normally appear to work well, but when confronted with a Byzantine pattern of evil flows, it blows up.

    ReplyDelete
  4. UnknownApril 4, 2013 at 10:35 PM

    > Is software defined networking really just OpenFlow?
    No. OpenFlow is a protocol, and is a small component of SDN. It's not even necessary to use OpenFlow to build an SDN (this is probably the future of SDN...)

    To clarify your understanding of SDN, read the articles Colin linked to above. I'd also highly recommend Scott's talk: http://www.youtube.com/watch?v=YHeyuD89n1Y

    ReplyDelete
  5. UnknownNovember 25, 2013 at 5:00 PM

    This question digs deeply into Pyretic's capabilities, but we don't have a formal framework to compare the capabilities of different SDN programming models. Time Tracking Software

    ReplyDelete

Subscribe to: Post Comments (Atom)