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), and Dmitri Kalintsev recently blogged “How 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?

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.

To find more about OpenFlow, watch our OpenFlow Deep Dive webinar; you might also be interested in How Networks Really Work webinar.