Software-Defined Networking and UC

In this Industry Buzz podcast, the UCStrategies team welcomes Manfred Arndt, distinguished technologist from HP's Advanced Technology Group focused on UC and mobility, to discuss Software-Defined Networking at HP. The conversation is moderated by Dave Michels, who is joined by Blair Pleasant, Dr. Joseph Williams, Phil Edholm, Steve Leaden, and Marty Parker.

Also on UCStrategies.com on this topic:

• HP Launches SDN Developer Kit and App Store, by Blair Pleasant

Dave Michels: Welcome to the weekly UCStrategies Podcast, this is Dave Michels and today we are going to be talking about a variety of topics with our guest from Hewlett Packard, Manfred Arndt, a distinguished technologist from the Advanced Technology Group focused on UC and mobility. Welcome, Manfred.

Manfred Arndt: Thanks for having me.

Dave Michels: We've got a lot of things to talk about with you, so let's start off really broad and help me understand because when I think of the conversations I have had with you, and where the industry it going, I keep on thinking about cloud, mobility and SDN, and those are some pretty big topics. Where does HP fit into this whole thing?

Manfred Arndt: Exactly, I think what you highlighted there are three key trends that we are seeing. UC is rapidly transforming from a PBX-lead solution to pure application play and this can continue to gain traction and adoption of mobility through smart mobile devices and as BYOD continues to expand inside the enterprise. This trend is being driven by the application centric and cloud-based solutions like Microsoft Lync, Office365, Sky ShoreTel, Skype and various others. But the problem is the strict performance demands that voice and video place on the network. And the quality of the user experience is only as good as the quality of the network. The users can get frustrated when the experience isn't what they have experienced on the landline especially in the enterprise when we are trying to replace the PBX. What we need is more application awareness is becoming critical for UC&C. In the desk phone days, in doing VoIP, things worked really well. The phone plugs into the network, it auto configures via LLDP or CDP, gets the right voice VLAN, gets the right QoS Policy, and life has been good.

But the world is changing and in talking to our customers we hear them struggling on how to do that in a soft phone manner or in mobile devices. And so I think we are seeing an opportunity that SDN or Software Defined Networking can really transform how we provision and deploy networks, and this is a really exciting time. I have seen more excitement in the last year than I have seen in the last 10 years of my career.

Dave Michels: For so long the UC space has really been all about the application and it seems like the network is waking up to this and the network is becoming far more central to the conversation now. And along those lines one of the things we talked about at the UC Summit was where HP is going with SDN's. Blair, why don't jump in and share your thoughts.

Blair Pleasant: One thing we were wondering about Manfred is how software defined networking relate to unified communications, because to a lot of us it still seems like something separate. And do you have any use cases that you can talk about, about customers that are doing SDN with UC?

Manfred Arndt: That's an excellent question because SDN kind of grew up in the data center and if you look today, SDN is really about the virtualization of the functions of the data center to do VMotion inside the data center of a server when it has to migrate to another data center and to do that overlay. But SDN can be a lot of different things to people.

We believe that SDN plays a very important role in the data center, but it also plays a very important role by bringing that application all the way to the user in the campus and branch. Having just the data center part is nice and important but the true experience is end-to-end, and we find the UC&C use case, and what we have demonstrated with Microsoft Lync is really the ideal and compelling use case that showcases so much of what SDN is capable of doing. It's about being able to provide a better quality experience from a QoS standpoint, it's about providing better enhanced security, it's about providing better network traffic engineering, things like load balancing. There are a number of very powerful use cases that SDN can enable that simply aren't possible in today's architecture.

Let me give you an example about how traffic lights work. Today's switches really are very autonomous, they do great functions but they are not very well coordinated. So think of a city which has a lot of traffic lights, and if you make independent functions and independent decisions, imagine that traffic trying to flow through the networks smoothly. You are constantly going to be stopped by a traffic light and voice and video is different than most applications. That traffic needs to get quickly from point A to point B as quickly as possible, but we all know that when we hit these traffic lights they always seem to trigger at the wrong point in time. And it is very difficult in current architecture of the network even with management tools to coordinate those independent devices to orchestrate and coordinate together. Now imagine we have a centralized control making that policy decision of these lights, and we now can optimize the flow of traffic throughout the network and make much better decisions. So for example if traffic loads or the freeway traffic gets more congested, we can reroute traffic around different points, or we can time the traffic lights so that all the lights on a main strip stay green while the traffic comes through and only changes it as needed instead of making random decisions.

Blair Pleasant: Okay, I love that analogy; it's something that I can understand. So what would you recommend to customers to be thinking about if they are interested in doing SDN with UC?

Manfred Arndt: Well, the important thing with SDN is one, to start getting familiarity with it because it is a very different way of doing things. In switches today, you provision them all on a box-by-box basis. With an SDN model that control or the logic is done centrally, but the actual forwarding of the packets is still done the same way. So part of it is really starting to become comfortable and familiar with the use cases of how it works, and the reality is, it needs to be done in a phased migration. You're not going to be able to just rip and replace everything overnight, so customers have to become comfortable with that experience and a great part is take a look at the demo of what we've done, the Lync SDN UC&C application demo on YouTube can give an example of what is possible. We've gotten such great customer feedback from this proof-of-concept demo; this has now being productized and something we will be releasing next year. So this is the great way for customers to understand the use case and what we can do with them.

Another great use case we have is around our Sentinel Security Application. This is a product that we've actually got deployed at a number of different customers. HBO has this deployed now, some school districts in Australia have this deployed, and what this allows us to do is provide IPS-like security to every port on the network rather than having to funnel that traffic through a central choke point or an expensive IDS-IPS box. So here are some very good use cases for customers to start looking at and gaining the experience of that, say in a pilot environment, in a beta environment, and once they gain experience with that then they can start rolling that out.

Blair Pleasant: Okay great, thanks very much.

Dave Michels: What I'm curious about and I want to turn it over to Joseph because he has a little bit more experience with this. Joseph what are you seeing?

Joseph Williams: This is exciting stuff and it's something that the enterprise customers want to hear more about. So Manfred, the question I would have is particularly in the branch and campus environment there is existing infrastructure already...rip and replace isn't going to work. How is this going to actually get deployed?

Manfred Arndt: That was an excellent question; thank you for asking that. Like you said, in the data centers, green field deployments happen, but I can't recall the last time other than an occasional branch here and there when people do green field deployments. So how can you roll this out across your infrastructure in a manner that doesn't require a wholesale upgrade, or one that I can get comfortable with a little bit and then migrate over time?

That's one of the beauties we find with the SDN architecture - it does support a hybrid model. So there's a way to continue using existing protocols, things like spanning tree or your routing protocols. If you have your network functioning, why do this whole paradigm shift of using a new mechanism to just do what you have done before? Our belief, and the way we are getting customers excited about them, is showing how SDN can solve some of the use cases that are really hard to do today. The QoS provisioning, for example, is one of those use cases. Doing the IDS/IPS on every access port. And what we are doing with those is we are doing that focused on that hybrid use case. So for both of those security applications and the QoS for Lync application, the only requirement is that you have SDN enabled in a hybrid manner on your access ports, and if you only want to start in one branch, for example, you can get that benefit in that branch site and then you can start turning on incrementally on more and more sites.

So for example what that means is, let's say that you have access layers that can support this capability using OpenFlow protocol at three or four branches. Those branches will get that automatic marking of the QoS or to get that security functionality on the ports that are deployed while you continue using current techniques on your other sites and as you become either more comfortable with the protocol, with the SDN architecture, or have more switches capable, then you can rapidly start igniting this on more ports. Now as an example we have been doing SDN even prior to the days of it being called OpenFlow, back in 2007. We've been working with Stanford, and as such we now have the OpenFlow technology implemented over 25 models of switches and growing, actually I apologize, it has grown now to 40 models of switches and our goal is to have every one of our networking switches support OpenFlow and we have over 25 million ports already deployed. So what this means is there are quite a large percentage of the customers out there that already have this technology embedded in the switches they bought in the last several years and may not even know it.

Joseph Williams: Let me play this back to you then using a different vocabulary. In the SDN architecture that you build, is the VAN SDN controller acting as an abstraction layer between the infrastructure and the applications that are going to take advantage of this, is that how it is actually functioning?

Manfred Arndt: Exactly.

Joseph Williams: The fact that there is legacy infrastructure won't be an impediment to deployment because of this abstraction layer that is in place that will retroactively deal with these legacy ports?

Manfred Arndt: Not really, the way the hybrid model works is we are only going to apply this SDN functionality for specific things. In this case we are going to have the SDN controller talking to the Microsoft Lync server getting information on what new call we are starting. This SDN controller then can on a per-call basis will program that access switch where that user resides with the right OpenFlow policy to remark the differentiated services or DSCP code point on an access switch for only that user so that UDP IP address source and destination port. So only that user's DSCP marking will be affected but the packet now throughout the rest of the network will flow how it has always flowed.

Joseph Williams: Now that is super helpful, thank you.

Dave Michels: Yes, I think that is very helpful, but now with OpenFlow we have to get into quality of service, so Phil why don't you jump in here?

Phil Edholm: Yes, it is actually an interesting discussion around SDN and so I guess one of the questions I want to understand is in the campus environment where we have high bandwidth, what is the advantage of SDN versus taking that other side, the API side, and combining it with traditional network infrastructures?

Manfred Arndt: Very, very good question regarding that. Going back to the campus edge, the biggest problem around QoS has not been the QoS model; the QoS model works really well. Once we know what an application is, we do that really, really, well today. We've got 64 code points; the industry has pretty much standardized on 13 of them are well defined; most organizations may use five or six if they are advanced and we do not have any issue with that. And that's why IP phones work so well. The IP Phone is trusted, the IP phone marks its voice and IP phone doesn't do anything else, so the world was good.

But along came Microsoft Lync, along came soft phones, and the challenge is I cannot recognize the application, I don't know what the end point is doing. It may look like voice but I am not certain, and to complicate the matter, many of these applications now can use a wide range of port pairs. By default, Lync uses ports 1000 through 65535, and that's pretty much the entire port range.

So how do we recognize that this is voice? We used to do DPI, Deep Packet Inspection. That doesn't work anymore because the call is encrypted. So when a call is encrypted, both the signaling and the media is encrypted, and they might not even be going the same path. The signaling goes to the data center and the media flows peer-to-peer; it's hard to potentially correlate that because that might not even be flowing over the same switch. So how do I recognize the application? Well, like you highlighted, that API provides a trusted model or the server in a trusted manner provides us the identity of the n-tupple of the flow characteristics of the flow itself to identify that. But in addition to that it provides us who the users are, what they are trying to do - are they trying to do voice, are they trying to do video, are they trying to do desktop sharing and how much bandwidth they need. So it provides us with a lot of information, very powerful information in a trusted manner. And that part allows us now to recognize and appropriately mark the QoS on the access switch, so now that marking stays in that packet for the entire life of the packet and allows the core of the network and the WAN routers even if they are not OpenFlow capable to do what they have done so well all along is to continue honoring the QoS. So the biggest issue was not really doing the QoS, it was understanding "is this the right application to be applying the policy to in the first place?"

Phil Edholm: Okay, I think that answers the question but doesn't really come to the key point which is, the marking data alone is the significant value, I'm still not sure what the value is of SDN in the campus in a high speed network environment where simple CoS will give you all of the SLA capability you need and the benefit of SDN there from these kind of flow control perspectives seems to me to be overkill.

Manfred Arndt: Agreed, from that alone SDN is potentially overkill because you have done a lot of new stuff just for the functionality. However, we see that SDN opens a door to so many more new use cases that the classical network management can't solve. For example, a big one is how do I do call admission control or how do I create a bandwidth manager that deals with between multiple applications? SDN allows us to centralize and truly create something that industry has been trying to solve for many years. We can direct where that packet goes as soon as it comes in irrespective of the network topology is and we can cause packets to flow in a manner that may not even be natural. For example, inside the mobility world, most people in the thin AP architecture channel all the packets to the core controller and back to the network. So that's not an optimal forwarding of packets from a voice standpoint, you want to go the shortest path. And even in a routing architecture if you have a layer three hop, packets will tend to go to the core router before you can forward it to different VLAN. In an SDN model, we can completely violate how packets would have normally been forwarded and we can forward the packets based on the best path of choice that the controller identifies so what that allows us to do is find the most optimal path, but we can also do that on a load balancing standpoint, and today load balancing is extremely difficult and you have to deploy very expensive boxes, it often costs tens of thousands of dollars and as such cannot realistically be deployed at every branch site in a very distributed nature. So what this allows us to do is take existing functionality that was hardware based, that's very expensive, and also tends to be a choke point in your network because these boxes don't scale to the high bandwidth you talked about. Most of these boxes don't run at that speed and if they did they are very expensive. So it allows us to take functionality that people want and embed in almost any switch, so a lot of these things like port mirroring, load balancing, policy based routing can now be applied to much more cost effective switches and almost anywhere within your network and I think that's the part where we start talking to CIOs and IT managers, once they understand that capability it provides, that's a paradigm shift, that's transformative, that's what they get excited about.

Dave Michels: You know you mentioned in there Manfred, you mentioned buying expensive boxes may not be needed and I know that nobody dislikes that than Steve Leaden, so Steve I think you are up.

Steve Leaden: Thanks Dave thanks Manfred for joining us. I'm actually doing a study for a client on Hurricane Sandy right now, and some of the aftermath of that and we are seeing that a voice over IP UCC solution can play much stronger to a DR model way beyond any kind of decentralized legacy kind of solution. So can you also speak to that briefly in your design with Lync?

Manfred Arndt: That was a great comment and I remember with Hurricane Katrina the same kind of comment was, the classical PBX was designed to support certain types of failures, but what if there was a flood or fire where your PBX was, you were screwed. It would take you months if not longer to do a DR. The beauty of these IP telephony-based solutions is if you need to deploy a new remote site or you need to deploy a new core, that's much easier to migrate those solutions. So most enterprises now have multiple data centers co-located and have a very robust DR mechanism between there, so there is no single point of failure anymore. HP has three regional pools like that so we can support multiple types of failures and ensure that there is no loss of service from a DR standpoint. And in the branch site, if something were to happen there in a site, or community or a town was completely destroyed, I don't want that to happen, but if it happens, you can now roll out a mobile site, say a truck or a trailer using say a WAN router with a wireless back haul. So even if there is no wire line to tap into, you could start using cellular service to tap back into the core infrastructure. So these are the types of things that IP telephone and VoIP enables that the legacy TDM never could. Provisioning new TDM circuits could take weeks if not months to deploy, while deploying new IP services especially over a mobile network can be like the flick of your finger.

Steve Leaden: Exactly, well thanks Manfred, back to you Dave.

Dave Michels: Alright, well I think we'd better wrap it up here with Marty Parker.

Marty Parker: Thanks very much, Manfred, for being with us today. We know that the HP team is working to make sure that your channel partners can take full advantage of the work that you've done to create the HP reference architectures for Microsoft Lync. It seems to me that these will save the channel partners significant time, the time that it takes to define and test the reference architectures themselves and may also speed up sales cycles so those customers have a clear starting point. Can you tell us more about this? How are the reference architectures being embraced by your channel partners and what benefits are your channel partners reporting back to HP?

Manfred Arndt: Hey Marty, good talking to you as always. And yes, good points. I'd like to step back even one step further than just a reference architecture. When Microsoft first came out with Lync they really were targeting large enterprise. Our strength from the HP networking standpoint has always really been the channel partner; we do a disproportionate amount of VAR sales through the channel and we have a good relationship with many of these channels. So we actually approached Microsoft and said look, we think there is a tremendous opportunity to take Lync and bring it into the mid market and we have been doing a campaign for that now over I think well over a year now where we have been targeting specific focused channel partner community to bring Lync to them and help educate them and help train them on how to bring that up. And that's been very successful. Because the channel partners are the ones that know these customers very well, they know their use cases, they know their specific vertical; that's not something we are able to scale to that level. We do well on large enterprises; they do well on the mid market and the specific verticals. So that's really been a tremendous success. But the part that they were challenged with is, as we all know, every customer can be different. The benefit of Lync is it is so flexible, but that is also the problem of how flexible it is especially for the smaller guy who doesn't have the same amount of resources and the staff to throw at that.

So these reference architectures are really well suited to give them a proven template, a tested template that they can be confident at, meets the right design guidelines to provide them a good quality experience so they can leverage that including a bill of material that they need to get. This doesn't mean they cannot customize it, but I've always learned that when I have a template on something no matter what it is, or cookbook, it is so much easier to follow and get started than a blank sheet of paper. If I am cooking a recipe I like to experiment, but I'd like to have something as an example to follow from. So our channels and our field has been very excited about the new reference architectures as something that was actually put together and actually tested because it is all too easy in these complex solutions to put a theoretical reference architecture on it and it only takes one or two mistakes in there to cause the complete solution to appear like it doesn't work. It may not be a big problem, but to try and identify where the breakdown is can take a long time to troubleshoot and diagnose, at least that has always been my experience.

Dave Michels: Okay, well I see we are going to wrap up this podcast. I would like to thank the experts and we will be back next week with a new topic. Thank you very much, Manfred.

Manfred Arndt: Well thanks for having me, great talking with you guys.