Microsoft Partners With Nectar on UC SDN

In this Executive Insights videocast, Dave Michels of UCStrategies is joined by Pascal Menezes, Principal Program Manager Skype and Lync Strategic Relations Solutions (SRS) for Microsoft, and David Giangano, CEO of Nectar Services Corp. The topic is UC Software Defined Networking (SDN).

Dave Michels: Hi. This is Dave Michels with UCStrategies. I'm at the Lync conference. I'm with David Giangano from Nectar, and Pascal Menezes from Microsoft. We are going to talk a little bit about SDNs today. Nectar is coming at it from a performance management and diagnostics monitoring perspective. I think that is a really interesting angle on SDN. Because we normally think about the physical structure of SDNs and the hardware associated with it. But the performance management, how do you get the information to do that? I think that's where we have a partnership. Let's start with this: you are what kind of partners?

Pascal Menezes: I would say maybe close to a year plus ago we started working with Nectar's team to actually develop this idea of a UC SDN. So the idea that the application, the unified communication application, specifically Lync, could actually go ahead and give information out to the systems, in this case network monitoring management performance system, and then it could take that information and figure out what is going on when something goes bad.

Dave Michels: So this is the same API used for any type - it could be hardware appliances or performance management?

Pascal Menezes: Yes. There are different scenarios. In this case the scenarios are around UC management diagnostics, automating diagnostics. We found the problem was, just to give you an idea, we were finding a lot of the times people were saying, "I am having problems with Lync." And 80 percent of the problems were network related; 60 to 80 percent were network related. When we would try to figure out what was wrong, it would take a long time to go through configs and figure it out. It was a really long process. Very expensive process diagnosing problems on calls. We came up with the idea that working with Nectar team we said, "Hey let's solve this problem by giving you this knowledge about a session starting and a session having degradation." Then they had this very unique technology that they can actually look at path computations of a session off IP address to end points they could figure out the path. And then from the path they can collect all this information on that path and while the media is running on it. Then when the media has a problem they can try to figure out was it a queue problem, or a packet dropping...

Dave Michels: You are not just watching the network. You are actually providing information about the type of quality you need and the type of application or voice data.

Pascal Menezes: Yes, exactly. And then how well that session is performing. Then we give it to them and they do all the intelligence.

Dave Michels: You do that dynamically. So if you start off in say, IM, and then you go to voice and then you go to video you are sending the updates. And you are using those updates to say, "Well now it is video and we need this type of quality of service," or are you applying different policies or rules?

David Giangano: Different policies and rules. Actually, if you look at it without the API, the information is encrypted. So we need to know information around the codec sets, the type of information that is going to be transversing, then actually what we can do is we can peer on a layer three layer and understand the end points and start and beginning end points. And if say there was a conversion in the network or a fail over, we actually see that in real time, so we can report on that. What we see sometimes is there is an issue on a network or a queue is not set up right. It can be working for the beginning part of the session and then there is a fail over and it can go into a queue that maybe is not set correctly. We will see that instantly. Then we can give actual insight back to the service providers or the enterprise customer in terms of where they have to go to remediate.

Dave Michels: This sounds pretty mature like it is all working today. Did it start off really mature? Give me a little idea.

Pascal Menezes: It began with an idea. And SDN as you know software defined networks were starting to merge out, there were data center, virtualization ideas. We took the idea that why couldn't an application like unified communication that has long flows have the paradigm that says give the information down through this web service out of band channel to a controller which is what SDN is all about, a centralized intelligence controller. When we looked at the scenarios there were many scenarios. The one that was really compelling was this idea of automated root cause analysis and diagnostics. Today at Lync we have this quality of experience database. It tells if we are having a problem with the session and the history and the time. When you get it and you look at it you have to go okay so we had 10 percent bad calls, what was the cause of that? Was it a gateway? Was it coming from the internet?

What we are finding as we went through these analysis with analyzers and people, it was 68 percent network problems. So we were really motivated to find out an automated way of doing this to a system. We started working with Nectar to do this.

Dave Michels: What we are trying to figure out is because I know the API was unreleased for a while. It became released - when did you make this available?

Pascal Menezes: We initially released is at Network Diagnostic API with Nectar back at last year's Lync Conference.

Dave Michels: So it has been about a year now.

Pascal Menezes: About a year. But then we evolved it to call it SDN API.

Dave Michels: There have been different versions of the API, and you have been creating those versions for them, for -

Pascal Menezes: Feedback.

David Giangano: It is collaborative. And we consume that API and use that as the foundation giving us the information that we need to then use our technologies really to look at end-to-end quality. I think what's really important, what we see is that there is a lot of tools out there that can do reports. Again, when we speak to our end customers or service providers that use us, when there is an issue it is always this: it is the network, it is the application? We look at the whole ecosystem of a UC deployment and from the applications to the underlying hardware and the services that run on it. And then how do you tie that - especially in a multi-vendor environment, where it gets complexity, where you have certain vendors that look, if it's all one vendor we can manage it. We really look at the real world where it is a best of breed and we see applications that cross those vendor boundaries and how do you manage that.

Dave Michels: This really has nothing to do with an SDN network. If an enterprise provider doesn't have an SDN network they can still use this information. SDN technology - almost like a precursor. You can start here.

Pascal Menezes: Absolutely.

David Giangano: We see it every day in the real world. I think if you look at what are we really trying to do you look at commerce or business how does it move along? It's through voice and video and collaboration. It is humanizing the technology piece. It is not delivering a monologue. How do we make it so that every call, every video call, every session, is clear, pristine and reliable? That is what we look to do and achieve.

Dave Michels: You mentioned service providers, who is using your technology? Is it just service providers? Is it large enterprise? What do your customers have in common? Describe that. Who can benefit from this technology?

David Giangano: Sure. For us, we originally built the foundation looking at the atmosphere of the service provider how can they deliver and manage complex environments from same site global deployments. We have an underlying technology that allows them to pull information back in real time and historical and manage hundreds and hundreds of customers with overlapping IP schemes and everything else. We handle that in a basic foundation layer. Then we build very specific vendor knowledge, modules. We call them DKNs. And it goes out and understands those applications in detail. And we discover those applications and bring that back. We have service providers that use us because we have routing and escalation protocols that we can use to meet SLAs. Then we have end customers that are say, self maintainers that can use us as a standalone model. Or we have a combination of the two where we have service providers working in collaboration with enterprise customers where they are both using the tool and providing insight, meeting SLA performance, and getting them the ability to lower TCO and improve operational efficiencies.

Dave Michels: Okay. Let me just ask - I heard earlier you said this API was encrypted.

Pascal Menezes: The media that Lync uses and the median signal is all encrypted. So if you try to sniff all that on the depack inspection gears, you can't really do that practically. You can do it with heuristics, but that is another story. The point is the API is an out-of-band web service that we give to them. Then they use it like an SDN controller paradigm technology. Yet they talk to the elements, SMP, CLI it doesn't have to be open flow.

Dave Michels: Is this API something that is available to every Lync customer?

Pascal Menezes: It is publicly downloadable. You can search Lync SDN API, you can download the API. You can install it on the front end. It is good for 2010, 2013 Lync. We will be shipping in-box for future versions. The API by itself is not going to do anything unless you have a partner like Nectar who is doing a scenario around it. Their specific goal was to take this API and using their great system they have in place, could they actively pinpoint a bad call, exactly where in the network was the bad call.

Dave Michels: In real time.

Pascal Menezes: In real time. Today, unfortunately, our API gives the information of a bad call at the end of a call. So it's almost real time. On our future version we will give it in real time.

Dave Michels: Talk about that. Let's hear about this API - there is a new version coming?

Pascal Menezes: There is a new version coming. If you saw the session on Lync we did one, Jamie and myself we talked about this. Today the API is very cool. It gives you session information, start and updates and so on. It gives you the quality of the session. We call it quality updates. Today it is only at the end of a call the way we have structured it unfortunately. The new version will come out and it is version 2.1 scheduled for that some three months plus. You will actually be able to give in-call quality updates that, "hey the call is having a problem right now." Now they can take that right now and do something with it.

Dave Michels: Until the end of the call the quality gets bad - just hang up.

David Giangano: The magic comes when you have so much information coming in, how do you correlate that information? How do you consume that API, use that and then correlate it with all of the other events that are being driven from. Whether it is an application event, whether it is in the underlying network. It can be delivered from the cloud. We see so many different scenarios where information can somehow get lost.

Dave Michels: So tell me, is your solution an appliance, is it a box, what is it?

David Giangano: We can deliver via the cloud; we can deliver on-premise.

Dave Michels: So you have a subscription model?

David Giangano: We have a subscription model or an op ex model; we have a cap ex model also. It depends on how they want to purchase and how they want to be supported. For customers that are self maintained we deploy what we call a RIG or remote intelligence gateway that will sit at the customer's premise there. Information stays local to their premise. And it goes out and pulls in all the information around health and performance so the applications and network and what is going on. Then it can push out what we call portal views or the ability to have dynamic dashboards that represent their whole ecosystem and those dashboards are live. Then down to drilling down to the underlying applications or what we call dependency trees in the architecture. So if there is an issue, what is that issue, where is it being created and information how to we remediate?

Dave Michels: If you have multiple Lync environments say you are a service provider you have multiple Nectar environments or is it one?

David Giangano: That's a great question. For us, we came at it from a service provider point of view. So we have the head end that sits at the service providers. And we call that a central intelligence platform. That goes down and then we have RIGs that can then aggregate the information at the customer site and then push and promote information up from the head end of the service provider. Then based on rules and authentication policies, that service provider can then get that information and then create actions around how we can remediate or meet the SLAs regarding performance.

Dave Michels: I have been saying for a while that UC is the killer app for SDNs. I was just thinking about the network provisioning. But from a real time monitoring perspective, I think this is very exciting. Thank you.