UCI Forum: Unified Communications and SDN (UC SDN)

In this Executive Insights podcast, UCStrategies' Jim Burton is joined by Pascal Menezes, Principal Program Manager Skype and Lync Strategic Relations Solutions (SRS) for Microsoft. The topic is the UCI Forum, and UC SDN (software-defined networking).

Also on UCStrategies.com on this topic:

• UC and SDN: Applications Controlling Networks, by Michael Finneran

Jim Burton: Welcome to UCStrategies Executive Insights. This is Jim Burton. I am here with Pascal Menezes from Microsoft. But we are not here to talk about Microsoft specifically; we're here to talk about the UCI Forum which Pascal is a member of. Can you tell us about your role and a little bit more about UCI Forum?

Pascal Menezes: Thanks, Jim. Thanks for having me, by the way. So the UCI forum was founded in 2010, about 32, 34 members - it changes and is growing. The goal of the UCI Forum was really to promote interoperability of the different types of vendor products. Everywhere from UC systems like what we did today at Lync, to Gateways and USB devices and cameras and so on. Get that interoperability up and working. There is a number of technical groups that are working on some very challenging ideas. For example, I was chairing the IBB6 group to do SIP v6. As you know, address depletion is a big issue so we now pretty well have a great tool set coming out to test interoperability around SIP v6. We are also doing something on H.264 for video to get the interoperability for that. The one specifically I'm now driving is a thing called UC SDN, software defined networks. I think that is really the innovative area I am focused on right now is how to make applications and network talk better together.

Jim: One of the big questions I have, and because you are an engineer, please don't take this as an insult. But engineers are often times solving problems that some of us don't understand exist. Sometimes you are way ahead of us and know that. What is the problem you are trying to solve here?

Pascal: That's great. I'm glad you actually asked that. Yes, you're right. We sometimes try to solve glitches for the sake of it's techy and it's cool. In this case I think we actually are onto something. I have been doing internetworking for almost 30 years. I think in 30 years, even from when I started even back in Bisync and X 25 when the IP and internet protocols came out nothing has really changed. And so in internetworking, we are still living in a 30+ plus years of technology nothing has really changed. The fundamental problem is what we have done is as we walked into the internetworking world 30+ years or more, we went to the packet paradigm. What happens is applications would just shove their application packets on the wire and it would just try to get across. And then we would have to put TCP to retransmit. The bottom line is that the networks have been evolving by getting more and more intelligence into them by trying to figure out what is going on with the application. We have these deep packet inspection technologies. All of the sophistication that is happening in the network just to find out what is going on with the application. What you have is this miscommunication of applications and network not talking to each other.

Fundamentally, what you have is, since they don't talk to each other they are like ships in the night just doing their own thing. Network is trying to figure out what is going on with the application. Application is trying to shove their stuff to the other side. And when it doesn't work, it retransmits, and the end result is you just don't get a great end user experience. The end user suffers. Whether it be in UC, somebody gets dropped audio, the video is freezing. Even, for example streaming video, on demand video. You know you have huge buffers it still sometimes can lock up because the network stops passing packets. These are examples.

Jim: Those are good examples. I understand there really is a problem to solve here. Now the question is, how are you going about solving that problem?

Pascal: I think what is happening, the reason I talked about 30-year-old plus internetworking not changing, is the paradigm in internetworking is always being put the intelligence distributed into every router and switch, what we call network elements. Back then we didn't have processor speeds, we didn't have memory. The idea is, how do you put that intelligence centralized is really what suffered on a network I was just describing -- take the control protocol that were all just decentralized and distributed. Centralize them into what is called the controller, and then the controller has this intelligence to it to be able to then program these network elements on-demand dynamically.

That's actually now coming into play. We are seeing that in the data centers as the first implementation scenario. When you are moving VMs the network has to accommodate for that. We learn what software defined networks is - this is a very strong paradigm that if a centralized intelligent, centralized control plane, programming in real time these network elements with just these kind of flow rules, then you have this central point, then why can't applications talk to the central point? In the old world of internetworking it was very hard for an application to talk to every node. That scale wouldn't work. Today we actually have something very cool in the idea that we can talk to this controller and then the controller can do the right thing to the network.

The interesting thing about what we do in unified communication is our applications are along the flows. So in like a web transaction where it might be a sub-second, that's not enough to program the network. The unified communication when you do voice or video, there are many minutes to definitely on average a half hour to an hour or more. It is a perfect kind of along the flow that can program the exact requirements into the network. Does that make sense?

Jim: Absolutely. And you can just see that it is going to make such a big difference in how these applications work. If you have an application and it is helping manage the bandwidth, it's going to have what it needs to deliver the rich experience people are looking for.

Pascal: That's exactly right. And the scenarios are endless to think about. When applications, end user applications, can actually talk down to the network and give it its requirements, it is very powerful. This is not just futuristic stuff. This is actually happening. We are seeing products ship out with this paradigm, where there is the UC SDN API and I won't talk from a certain UC vendor that is actually delivering this with partners, and showing these kind of rich scenarios. It is very powerful. Very, very powerful. The net result is you get a lower cost of operations for TCO. You get a higher performance of the application working better. And the end users love it because things just work flawlessly.

Jim: It sounds like it is going to be easier to manage. It sounds like the cost will be down, which you mentioned, why wouldn't they love it? Well, one of the things that you bring up though, you say it is already kind of started, but where are we in the cycle? I know a lot of times when you get started on something before you can see it in momentum you have to go through several steps. Where are we in the cycle and when is this going to be really mainstream?

Pascal: That is a great question. Everything in technology takes time and it's crawl, walk, run. I would say we are in the crawl/walk area. It needs to standardize. What the UCI Forum is doing is it is standardizing a set of use cases right now under the UC SDN Task group, which I'm chairing. What we are doing is we are describing these very detailed use cases with the information models and what it needs to do as a scenario. We are working in liaison with the Open Network Foundation, which is like the SDN Forum. They have created this Northbound Interface Group, that's from the controller talking to these applications like ourselves. I am a vice chair on that group. Under the end user apps it is domain specific to make that work. The nice thing is that we are standardizing this. We are in the works of standardizing it. The UCI Forum, the UC SDN task group is about to sign off on the first use case, automating quality of service. Quality of service is very expensive to deploy, very hard to maintain, and we have got a very great use case once we sign off by the board, end of the month kind of thing. Then we will bring it down the open network foundation. I will then receive it as part of that group and work with our group to actually describe that API.

Jim: And you have a day job too besides all of this?

Pascal: Yes. It is all blended.

Jim: That's good. It begs the question because I have been involved in standards for a very long time and I understand the complexity and the time it takes. One of the most important things is getting support from all the various vendors out there. I know you've got a good, critical list of people that are part of the UCI Forum, but I have to believe that you are always looking for new people to join that can add value and help support and participate. Where are you on that? Are you looking for new vendors?

Pascal: Yeah, absolutely. We are definitely looking for all kinds of vendors whether it be network vendors or UC vendors with the session border controllers, gateways, routers, switches, Wi-Fi. Because at the end of the day it is about UC systems talking to end user apps. In this case let's be specific, UCI Forum: the UC systems talking to these network components. If we can make that work really well with all of these different use cases, very powerful for users.

I just want to recap. Today we are talking about automating quality of service, which is very expensive to deploy and maintain. You need to get it right the first time. Then you need to keep that consistency. From our experience of our own deployments, for enterprise voice UC you need to have voice service provisioned end-to-end. And keeping that every router, every node, having the right policies, it is very expensive to maintain. Automating that has become our first priority. Behind that there is a huge use case around traffic engineering, call it mission control, wifi, security for IDS IPS, DDOS attacks, diagnostics. That has got to be - trying to find what is wrong when something goes wrong. There are so many layers of deeps to figure that out and it is expensive. If you can automate that cause that root-cause analysis, very powerful.

Jim: One of my observations following this industry as I have for so many years is the companies that get engaged and get involved with helping set the standards and driving these trends, they end up being the market leaders. Those people that are sitting on the sidelines kind of waiting to have someone else do it, they are followers. I really encourage those of you that are out there who are thinking about this who might see this as important to give consideration to join the UCI Forum. It is going to add some real value to what you can do and the success you might be able to have.

Pascal: Yeah. I totally agree. The more we get people involved in this, the more we drive to a standard, it benefits everybody. What we don't want is locked in proprietary versions of this. Because it fragments everybody, and at the end of the day the end user loses.

Jim: Absolutely. What is interesting again, following this industry as I have there are a group of vendors out there who talk about being open. It is not in their interest to being open. They are big enough vendors they are just closed, they can kind of control the customer. I think the end customers they are smart enough to know what is going on. Sometimes it has been an advantage to be with one vendor historically. We have seen a few of those. AT&T a few years ago was the classic case. As we move forward we realize that openness is the important thing. I think it is one of the things we will see the vendors who join the vendors who don't. We will kind of get a message if it is a big vendor who doesn't join, they might like the closedness as opposed to being open.

Pascal: You are absolutely spot on. I think the call to action actually not only all the vendors out there, network vendors, UC vendors come join in, but also the end user enterprise customers to tell their vendors that we want this. Please join and make this a standard because we want to operate our networks much more cost effectively. The cost of the complexity and the cost is going outrageous. For the complexity to continue to go up the cost of people to manage that and make it all work is enormous and it affects their bottom line.

Jim: If you can eliminate it, why wouldn't you?

Pascal: Or at least mitigate it, reduce it, automate it. The agility itself is real important. At the end of the day businesses are now relying on their applications to make their work flow happen. It is very important all of those applications work correctly all the time and not be frustrating to use.

Jim: I understand at Enterprise Connect you are having a special session to discuss exactly what we are talking about here.

Pascal: Yeah. Absolutely. That's a great point. At Enterprise Connect actually there are a bunch of sessions in this area. Open Network Summit I think in the first weeks of March. There will be a session around this showing this UC SDN API working with a bunch of vendors that actually will be on stage demoing actual live products, shipping products in most cases, working with this kind of UC SDN API. That's a proprietary version today trying to get to standardized. Right after that we will be at Enterprise Connect doing a similar session. Then we will have another session at Interop, a little different more of a panel type. I think the buzz is on. The user interest, the user community meaning the operators, enterprise operators and so on, just see this as so much of what they need right now to manage the deployment of UC.

Jim: Great. We will put links to those three sessions below so people can follow up with that. It has been great. Do you have any parting comments you would like to make?

• Open Networking Summit 2014: http://www.opennetsummit.org/index.html
• Enterprise Connect: Unified Communication and SDN (UC SDN) http://www.enterpriseconnect.com/orlando/schedule-builder/session-id/96
• INTEROP: SDN Perspective panel: http://www.interop.com/lasvegas/schedule-builder/session-id/86

Pascal: Let's see. That's a hard one to answer. Parting comments... I would really encourage vendors to join. If we really want to make a difference we have a paradigm change possible now. We have never had the ability of applications talking to networks. We tried with RSVP, we tried with a bunch of things, it never really worked. Internetworking then was just not correct, it was distributed, you just couldn't make it work in the right way. Today we literally have with this software defined network wave coming out, for the next 5 to 10 years that will be a retooling of internetworking. We now have the ability to plug the application and give the requirements into the network. Say this is a flow, this is a session here are my requirements. And by the way, during the session if it's having a problem it can tell the network it is having a problem and do the right things, adapt itself, correct itself or even spit out where the problem was diagnostic wise if it can't fix it so people can plan it correctly.

I think this automation idea, the agility idea is powerful now. I think the leading statement I want to make is that we have the ability now to make a huge difference, a paradigm change, not only in internetworking fabric, but from applications talking to networks. Does that make sense?

Jim: Absolutely. Pascal, thank you for your time today.

Pascal: Awesome.