I’m a collaboration guy so why am I daring to write about Software Defined Networking, why should I care about it and more importantly why should my customers who run Cisco communications applications be interested? For me it goes back to the early days of IP Telephony when I used to start off every presentation with a picture of big old-world PBX next to my corresponding IP voice components. My message was simple and remains so; the IP routing and switching network was and still is analogous to a PBX’s backplane. Remember that even in the old days those TDM switches could support both voice and video. If the industry is going to start changing the way IP networks are fundamentally architected, I believe it’s important for me and everyone working in the collaboration space to try and understand the anticipated benefits of this new technology as well as any possible challenges.
Who knows what SDN is? In overview it’s a decoupling of a network’s control plane from its switching plane, which means the system can benefit from centralised control (via SDN Controllers) and this allows for centralised orchestration and a host of other benefits such as a reduction in cost of the network infrastructure. For a generic explanation of SDN please refer to the following public domain white paper “Software-Defined Networking: The New Norm for Networks”, or alternatively you can simply search the internet or the Cisco web site as there are a huge number of documents out there that discuss the subject.
From a collaboration perspective one of the anticipated benefits that got me excited is around improved end-user experience due to the fact that applications will be provided with a view of the network’s global state information so they can transparently adapt their behaviour. It sounds great but what does it actually mean? Here is a possible example; we all know that interactive immersive video results in a high bandwidth bi-directional data-stream that is very sensitive to parameters such as delay, jitter and packet loss. When our video session encounters these network conditions outside of industry agreed norms then the user experience will definitely be poor. What I think SDN will offer for collaboration is a way for very sophisticated management tools to continuously monitor state information in the network and in the event of degraded performance of an identified stream, in our example immersive video, have the ability to switch it dynamically to an alternative path through the network which meets the end to end performance prerequisites of the application. Can’t we do that with QoS and CAC (Call Admission Control) today? Not really, QoS will protect the video stream against data applications and CAC will protect our video stream against other video streams but neither of these mechanisms can dynamically switch a poorly performing video conference to a completely new path in the network. In one fell swoop we have kept the CEO happy who’s video we just automatically repaired (always a plus point for IT), we have maximised our bandwidth investment by utilising a redundant path through the network and we’ve probably improved the performance of the other applications that were previously being squeezed by the bandwidth hungry video stream.
In reality, there are a large number of challenges that will need to be overcome before SDN allows us to reach the state of utopia I’ve just described. For my above scenario one of the main issues I see is that it may not be easy to identify the collaboration application in the first place, for example, what happens if the CEO’s video application is opaque to the network because it is actually a WebEx conference that has his HD (High Definition) video bundled with web traffic in an HTTPS connection. How do we identify it? If we can’t, then how do we know (without being angrily told) if it’s actually experiencing those network related issues I mentioned earlier? I think it’s true to say the historic 5-Tuple approach to application identification is already sub-optimal even for our current Layer 2/3 platforms.
From a Cisco perspective I believe there is a role for Medianet within a new SDN enabled architecture as its ethos is to provide application flow level visibility and also incorporates a mechanism to troubleshoot specific packet streams from source to destination. For those of you not familiar with Medianet you can learn some more about it here. One of the advantages of Medianet is that it makes use of an application element called a Media Services Interface (MSI), which is currently bundled with Cisco’s main stream video applications and endpoints. This in turn allows the application/device to tell the network whether a specific flow is Jabber HD video, embedded WebEx video or even immersive video. We do this by pushing metadata into the infrastructure, which now allows the Cisco network to have granular visibility of all the Medianet enabled traffic. Medianet is not limited to only Cisco collaboration, it can also be utilised by 3rd parties and different types of applications as demonstrated by the recent joint Cisco and Citrix announcement. Which means as SDN evolves Medianet MSI application coverage could also be increased to solve lots of different types of infrastructure visibility problems.
The following SDN and Medianet “mash up” diagrams attempt to explain how I think a synchronous relationship could work. The schematic below shows a point to point SDN Jabber video session and you can also see an example of the additional flow information provided by both of the Jabber MSI clients. Our injected metadata can be used to identify the Jabber video stream at each hop through the network, which then allows the system to build a metadata flow database for each of our network elements. I’ve put the database(s) into the Control Plane so the network management application shown can have easy API access to it.
In my hypothetical Medianet enabled SDN environment the Jabber video SLA requires me to periodically perform a hop by hop Mediatrace for Albert Albatross’s Jabber video connection (as he is the CEO) to verify if he is receiving an acceptable service. By analysing parameters such as packet loss, jitter and latency at each hop of the underlying SDN network it’s relatively straight forward for the Collaboration Management platform to identify if there is a problem and then signal the Control Plane to do something about it.
As this is a SDN environment, then it should not be too hard for the flow to be redirected to an alternative path. Sounds good, but how do we know if the secondary path will be any better than the original? We actually don’t unless we test it first, so it would make sense to design the system so that the Collaboration Management tool could invoke a pre-emptive Mediatrace along the new path. Assuming that the trace passes the new hop by hop analysis, then we can safely switch Albert’s video.
Of course there are obviously hurdles to overcome before any such automated system can come to fruition, including wide spread MSI adoption and the development of reliable closed loop feedback signalling between the various system components, but those are issues smart people in engineering will need to grapple with.
Time for a sanity check, does what I’ve described in this blog sound logical or am I missing something fundamental? I’ve got to admit that the term self-healing network is not new to me but I think there is potential for SDN in conjunction with technologies such as Medianet to take that concept to the next level!