Maybe the only technology that has received more recent hype than WebRTC is Software Defined Networking. SDN represents the latest evolution of an approach that first reared its head in the late 1990s, then referred to as "policy-based networking." The basic idea was that applications could talk to the network to request appropriate services such as QoS/CoS and bandwidth.
SDN evolves that concept even further, breaking apart the pieces of the network responsible for making forwarding decisions from the underlying hardware responsible for implementing those decisions. Proponents tout a variety of benefits such as simplified and cheaper network infrastructure, more flexibility in routing and forwarding algorithms, and potentially the ability to provide application interfaces into the control plane (for a great tutorial on SDN, and the OpenFlow approach to controlling the data forwarding plane, see http://www.openflow.org/wk/index.php/OpenFlow_Tutorial)
So what does SDN have to do with unified communications? Quite simply, SDN offers the potential to implement dynamic provisioning of networking resources (again, QoS/CoS, and bandwidth) to support the needs of real-time applications.
Configuring IP networks to support voice and video used to be fairly easy--you assign voice and video endpoints into separate VLANs and use 802.1p at Layer 2 and DiffServ code points and corresponding queuing algorithms to prioritize rich media at Layer 3. If you want to get really granular, you can even prioritize the media stream (usually RTP) higher than the signaling layer (e.g., SIP).
But that straightforward approach is under fire as organizations increasingly move away from "desktop phones for all" to a mixed environment that includes softphones running on PCs and laptops, and mobile UC clients running on smartphones and tablets (almost half of companies are extending UC services to tablets, according to Nemertes' latest benchmark). Once IPT and video are simply just another application on a computing device, it becomes much more difficult to prioritize them across the network.
Couple the trend toward software-based UC with the increasing reliance on WiFi and cellular networks (about 17% of employees on average are wireless-only), and delivering network services to support voice/video gets even more difficult. And there's another new wrinkle, as vendors turn on encryption technologies such as SRTP by default. If the LAN and WAN can't recognize the type of traffic (because it's encrypted), they can't prioritize it!
So this brings us back to SDN. As Kevin Kieller noted back in April, UC vendors are exploring SDN to potentially solve some of these expanding challenges. One such example is Microsoft's partnership with Aruba to enable Aruba WiFi access points to detect Lync traffic and adjust QoS parameters accordingly, prioritizing real-time traffic generated from Lync ahead of other types of traffic traversing the access point.
Another example was covered in April as well by Phil Edholm, in which an HP OpenFlow SDN controller could dynamically allocate network resources to support Lync. Yet another example comes from startup Ubicity, which is developing SDN capabilities to support voice and video. More recently, Sonus and Juniper announced a partnership to integrate SIP services with SDN. Juniper had previously partnered with Polycom to enable Polycom platforms to request network resources to support video conferencing sessions.
We've come a long way from the policy-based networking framework of 10+ years ago, but the problems we are trying to solve remain the same--ensuring that the underlying transport network can dynamically react to, and support the needs of real-time applications. IT leaders should spend some time with their trusted advisors and their infrastructure vendors to learn how SDN can potentially solve ever-increasing bandwidth and QoS provisioning challenges. And they should ensure that those responsible for network management (or managing outsourced service providers) are working hand-in-hand with those responsible for UC deployments to ensure a successful rollout of the overall service. It probably wouldn't hurt to take a look at RFC3198 again too.
Follow Irwin Lazar on Twitter and Google+!
@imlazar
Irwin Lazar on Google+
