Do UC SDNs?

By

I’d like to make some key points about SDNs.

First, UC is the killer app for enterprise-wide SDNs.  I wrote about this at SearchUC here.

However, UC will not be the driver of SDNs, nor are SDNs going to be immediate.

There’s indeed elegance in separating the control plane from the forwarding plane, just as there was elegance in separating server CPU and storage from the server. Centralizing the control allows smarter and faster changes to provisioning and allocation of bandwidth while also lowering the cost of distributed switches.

There are many drivers for SDNs, but three in particular are worth noting:

  1. Ongoing virtualization of the data center is the primary driver. This allows organizations to dynamically allocate resources as needed, but networks hate it when servers move. The primary way to fix this today is big honking data center switches, but that isn’t always practical. This is such a big driver, that many believe SDNs only apply to the data center. That’s like saying we should only treat patients with brain injuries because the brain is more important than other organs.
  2. IP networks were never designed for voice or real time communications. Everything about IP networks screams not to use it for real time communications. Unfortunately, the screams were ignored – or at least lost in transmission. There are several problems, but IP networks are inherently best effort and packet agnostic. There’s been many work arounds such as VLANs, reserved bandwidth, p/q tagging, prioritization by device, prioritization by traffic type….all of which are difficult (read:expensive) to manage.
  3. It’s time for disruption. While just about every other aspect of IT has gone through one or more disruptions in the past twenty years, networking really hasn’t. Networking has enjoyed the sustaining technologies playbook – faster, bigger, better. All this surrounding innovation has put networking in a bad light, it is increasingly seen as the “weak link” of IT. Tremendous networking innovation is taking place now, via SDNs, from firms such as NEC, Avaya, Huawei, Juniper, and HP – all with the  disruption playbook in hand. Cisco, as the networking market leader, has the most to lose.

Cisco’s take on SDNs is different than the rest of the industry. It sees SDNs as more evolutionary. There’s nothing inherently wrong with Cisco’s view, but it doesn’t address the innovative disruption rumbling across the industry. This was painfully illustrated when JP Morgan recently downgraded Cisco. JP Morgan evaluates financial performance, not technical strategies – yet found fault and misrepresentation in Cisco’s business plan because it expects SDNs to cause intense pressure on Cisco’s networking services and fees.

I see HP, NEC, and Avaya getting very aggressive with their SDN solutions and the pitches sure sound disruptive – market acceptance is an entirely separate question.

SDNs are still a way out from becoming mainstream – certainly enterprise wide. Not because the tech isn’t ready or from lack of benefits, but rather because the market doesn’t understand SDNs yet.

SDNs within UC are going to be very important, but UC is only one of many network flows. We need to think of SDNs broader than data centers and broader than UC – and rather as a means to deliver converged unified networking. At this time, no UC vendor has yet embraced SDNs – it just is not a priority yet (that will drive sales). As I wrote in Search UC: tightly integrating UC with the network will ensure that bandwidth and resources get properly provisioned. Unified communications is a killer app for end-to-end software-defined networks because it is dynamic and thirsty for responsive bandwidth.

HP and Microsoft demonstrated a proof of concept with an unreleased Lync API (see prior post here). It is actually pretty compelling. There’s lots of comradery between long time partners HP and Microsoft. HP embraces SDN with the OpenFlow standard, so the same concept should apply to other OpenFlow compliant vendors, such as NEC.

NEC’s OpenFlow implementation is called ProgrammableFlow and evidently Microsoft likes it too. In this video, Mike Schutz, General Manager of Product Marketing Server and Tools Marketing Group explains how Microsoft is working together with NEC to deliver integrated SDN solutions.

He talks specifically about Microsoft’s Windows Hyper V and System Center working together with NEC’s ProgrammableFlow switches and controllers to realize “new levels of flexibility and agility.” It’s a data center view, but easy to extend to the enterprise – a laptop going from IM to video and then shifting the video to a Wi-Fi tablet requires networks to dynamically manage QoS and bandwidth across wired and wireless networks while knowing/aupporting that servers and clients can “change” on the fly. UC is like no other end-to-end app.

Avaya is taking a different approach with SPB. Avaya’s approach is arguably simpler, but can’t leverage existing equipment as easily as OpenFlow compliant gear. Avaya has some strong networking capability that it picked up from Nortel which it picked up from Bay Networks which stems back to Welfleet.

It is interesting to note that Cisco, Avaya, NEC, Huawei,  and Alcatel-Lucent all make UC solutions AND SDN gear. Unfortunately, Unify recently sold its Enterasys division last year.

Dave Michels