Your browser failed to load CSS style sheets. Your browser or web proxy might not support elliptic-curve TLS

Building network automation solutions

6 week online course

reserve a seat
back to overview

Bandwidth-On-Demand: Is OpenFlow the Silver Bullet?

Whenever the networking industry invents a new (somewhat radical) technology, bandwidth-on-demand seems to be one of the much-touted use cases. OpenFlow/SDN is no different – Juniper used its OpenFlow implementation (Open vSwitch sitting on top of Junos SDK) to demonstrate Bandwidth Calendaring (see Dave Ward’s presentation @ OpenFlow Symposium for more details), Greg Ferro was talking about the same topic in his fantastic Introduction to OpenFlow/SDN webinar, and Dmitri Kalintsev recently bloggedHow about an ability for things like Open vSwitch ... to actually signal the transport network its connectivity requirements ... say desired bandwidth” I have only one problem with these ideas: I’ve seen them before.

In the last 20 years, at least three technologies have been invented to solve the bandwidth-on-demand problem: RSVP, ATM Switched Virtual Circuits (SVC) and MPLS Traffic Engineering (MPLS-TE). None of them was ever widely used to create a ubiquitous bandwidth-on-demand service.

I’m positive very smart network operators (including major CDN and content providers like Google) use MPLS-TE very creatively. I’m also sure there are environments where RSVP is a mission-critical functionality. I’m just saying bandwidth-on-demand is like IP multicast – it’s used by 1% of the networks that badly need it.

All three technologies I mentioned above faced the same set of problems:

  • Per-flow (or per-granular-FEC) state in the network core never scales. This is what killed RSVP and ATM SVCs.
  • It’s pretty hard to traffic engineer just the elephant flows. Either you do it properly and traffic engineer all traffic, or you end with a suboptimal network.
  • Reacting to short-term changes in bandwidth requirements can cause interesting oscillations in the network (I’m positive Petr Lapukhov could point you to a dozen sources analyzing this problem).
  • Nobody above the network layer really cares – it’s way simpler to blame the network when the bandwidth fairy fails to deliver.

You don’t think the last bullet is real? Then tell me how many off-the-shelf applications have RSVP support ... even though RSVP has been available in Windows and Unix/Linux server for ages. How many applications can mark their packets properly? How many of them allow you to configure DSCP value to use (apart from IP phones)?

Similarly, it’s not hard to implement bandwidth-on-demand for specific elephant flows (inter-DC backup, for example) with a pretty simple combination of MPLS-TE and PBR, potentially configured with Netconf (assuming you have a platform with a decent API). You could even do it with SNMP – pre-instantiate the tunnels and PBR rules and enable tunnel interface by changing ifAdminStatus. When have you last seen it done?

Looking for the Holy Grail?

So, although I’m the first one to admit OpenFlow is an elegant tool to integrate flow classification (previously done with PBR) with traffic engineering (using MPLS-TE or any of the novel technologies proposed by Juniper) using the hybrid deployment model, being a seasoned skeptic, I just don’t believe we’ll reach the holy grail of bandwidth-on-demand during this hype cycle. However, being an eternal optimist, I sincerely hope I’m wrong.

Need help?

If you need technology-focused consulting, evaluation of emerging technologies, second opinion, or a review of your network, check out the ExpertExpress service.


  1. The first thing I thought of was RSVP and how it doesn't scale well.

  2. Actually, of more interest than bandwidth-on-demand is enforcing dynamic bandwidth sharing and guaranteed throughput in a policy driven way - more complex as compared to simple aggregate Diff-Serv stat-mux and flow-rate fairness. Quite often this goal does not even require any application-side support, but rather a centralized arbiter having network topology and application deployment awareness. Granular policy enforcement could be done at the network edge (ToR's/Server Network Stack/Software switches), which results in benign growth of configuration state density. The amount of research work done in this area is tremendous (apparently a hot topic ;) - you may be already aware of the following projects (some of them come from Microsoft ;).

    + others - thousands of them!... ;)

  3. I knew you'd give me tons of links to read. Thank you!

  4. You know... I wonder. If we had a round thing.. something that could roll... hmm.. we will build this. And call it the wheel! Viva la revolution!

    Didn't we hear during the hype-curve that network is the mainframe of our times. Old. Stagnant. Constantly farting and losing its dentures. *sigh*


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.