TechNote on Unified CommunicationsI can see that SDN can help with some of the issues raised in the article but not all.
Dynamic allocation of high priority bandwidth - fine.
But you need a WAN which allows for that allocation so it still needs to be sized for the potential use. Your underlying plumbing needs to treat that traffic as high priority as well whenever it is on shared infrastructure.
You need SDN capable connectivity to the cloud based Skype farm - which was one of the disadvantages of what this is supposed to compete with?
And it isn't going to help with remote users on the Internet.
Then identifying which aspects of the traffic are which encrypted flow is still the same - or even worse if it is all forced down the same tunnel even if it would have been local?
So the main advantage seems to be the side effects - dynamic allocation of bandwidth might allow for connection limiting since the controller knows about requested pipe sizes.
Finally
- this only works if the application predicts and requests the right bandwidth.
- this is in the call setup path so may increase the call connect time?
The concepts of dynamic allocation of high priority traffic and WAN resource optimization are intimately tied together. Being able to dynamically determine what traffic flows across the WAN means that WAN resources (bandwidth) do not need to be pre-reserved which in turn makes it is possible optimize the utilization of the WAN and significantly save on required bandwidth.
As for the value of using an SD-WAN solution for enhancing Skype for Business service quality, it is based on taking advantage what Microsoft provides with their own SDN interface. By having real-time communications between the Microsoft UC SDN and the controller of an SD-WAN solution, it is possible manage the underlying transport to accommodate specific requirements for each Skype session, including mid-session changes.
Typically an SD-WAN solution does not require an application to request the right bandwidth, but rather the Enterprise or Service Provider deploying the SD-WAN solution configures (associates) WAN requirements with business policies per application. The transport layer is then orchestrated with rules to ensure these WAN requirements are enforced on a per application basis.
And finally your point about this this being in the call setup path is not quite correct. The SD-WAN controller is not in the call setup path. While it is true the SD-WAN controller needs to orchestrate the underlying transport, once that is done, it is only performing packet forwarding which does not add any additional time to the call connect time.
Thanks for your comments!
This is nice use of SDN in network. But how do you see to apply same orchestration based application in core network. if congestion is occurring in between some path, if it will be able to switch that path or will be able to detect that path based on congestion? Can it choose alternate path based on congestion?
Yes, the SD-WAN controller would be able to switch paths based on congestion. Based upon statistics on packet flows that are sent from the switches to the controller, it would be possible to determine if a specific path is meeting the SLAs defined for that flow.
If the SLA is not being met due to network congestion the SD-WAN controller will identify a different path that will meet the SLA requirements, presumably one that is not affected by network congestion.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Great overview of the macro-factors impacting UC-as-a-Service and UC over the Internet in the Enterprise. The shift to the cloud continues to pick up steam.
The ability to leverage the Internet as a reliable, quality and secure transport has always seemed impossible in the past given the best effort nature of the Internet. With SD-WAN that is changing.