Downloaded 10 times
Uploaded byIMTC
UC SDN
This document discusses UC SDN (Software Defined Networking for Unified Communications). It provides background on UC SDN, including its goals of improving visibility, control, automation and agility for UC networks. It also discusses the growth of the SDN market. The IMTC UC SDN task group is standardizing UC SDN scenarios and certification programs. It encourages readers to get involved by downloading use case specifications, joining the UC SDN working group, building new UC SDN scenarios, and implementing UC SDN pilots.
More Related Content
UC SDN
- 1. UC SDN Pascal Menezes– Principal Program Manager Skype for Business Chair IMTC UC SDN Vice-Chair ONF NBI Former Vice-Chair of WFA MM Chris Lauwers – CEO and Founder Ubicity Co-Chair and Editor IMTC UC SDN
- 2. Poor visibility Complex QoS BYODshortcomings Network security complexity >60% Poor Calls - Networks
- 3. What is UCSDN SDN Controller Northbound API Southbound API Southbound APIs (OpenFlow, etc.) Northbound APIs (RESTful; undefined) Data Center WI-Fi Campus WAN LTE Cisco Jabber Microsoft Lync Apple Facetime Microsoft Skype Google Hangouts UC Apps Programing and Communicating to Networks
- 4. SDN market 2018forecast of up to $35 Billion1 In next five years, Global SDN market is forecast to grow at a CAGR of 62.3 percent. 2 By 2014, nine of the top 10 network security vendors will support OpenFlow. 3 By 2017, 60% of enterprise private cloud deployments will automate the provisioning of information security controls. 3 75% of Gartner clients are either thinking about or evaluating SDN4 1 - http://www.sdncentral.com/sdn-market-sizing-2013-april/ 2 - Global Software-defined Networking Market 2014-2018 3 - Gartner: The Impact of Software-Defined Data Centers on Information Security 4 - Gartner: Four Key Questions to Ask Your Data Center Networking Vendor SDN Market Dynamics “Higher-layer application functions will become integrated with lower layers of the network, leading to two-way application awareness. The network will be able to adapt to changing application requirements efficiently and effectively. In other words, applications will be able to dictate what the network needs to do to support them.” – Julie Kunstler, Ovum Research March 18, 2013
- 5.
- 6. Dialog Event UC SDN Interface Events: • Quality Update eventfor Voice, Video or Data Attributes: • 5 Tuple Value • NMOS Value • Delay Value • Jitter Value • Packet Loss Value • Healer Ratio Value Quality Event Network Elements Signaling Media South Bound API U C U C U C UC
- 7. Dialog Event UC SDN Interface Events: • Quality Update eventfor Voice, Video or Data Attributes: • 5 Tuple Value • NMOS Value • Delay Value • Jitter Value • Packet Loss Value • Healer Ratio Value Network Elements South Bound API Quality Event Signaling Media U C U C U C UC
- 8. Network Event UC SDN Interface Events: • Network Update Attributes: •5 Tuple Value • B/W Value • AP Wi-Fi RSSI • AP SNR • AP Retransmissions • Router queues • Packet drops • etc Network Elements South Bound API Network Update Event Signaling Media U C U C U C UC
- 9.
- 10. International Multimedia Teleconferencing Consortium (IMTC) WebRTC CTI SIP Telepresence Media Relays UCSDN Task Group Standardizing UC SDN scenarios and certification programs Standardizing UC SDN UC SDN Liaison Agreement Open Network Foundation (ONF) SDN Forum North Bound Interface (NBI) Work Group Defining NBI specifications End-User App NBI Sub-Group Automating QoS Use-Case Spec Automating Diagnostic Use –Case Spec REST Real-Time Media NBI Spec REST Resl-Time Media Reference Code
- 11. Why UC SDN •Address increasing complexity • Realize operational efficiencies for on-prem and cloud-based UCaaS • Improve agility for network operations, management and configuration Visibility Control Automation Agility
- 12. Call To Action •Download the UC SDN Automating QOE Use Case http://lp.imtc.org/IMTC-SDN • Join the UC SDN AG at www.IMTC.org • Build new scenarios for UC SDN • Specify UC SDN for new equipment purchases and upgrades • Implement UC SDN solutions today starting with pilots
Editor's Notes
- #3 First click – however, new challenges have come to light (bigger, faster, etc) Second click – Off main monitor Poor visibility: Need the ability to correlate Complex QoS: how do we simplify? In demo BYOD: UC diff beast (50% email vs 50% voice call example to slide to) 60% poor calls However we have a new set of challenges. After analyzing numerous customer UC deployments of real-time media we have concluded that many poor UC real-time media calls are the cause of the network. It is very difficult for enterprise administrators to gain visibility into when a call goes bad as to what is the root cause of the problem. Without having the ability to correlate a call across a network and understand what network defects were occurring during the call, UC real-time media diagnostics becomes very difficult, timely and difficult QoS is complex and a black art to deploy. Not only do we have various variations layers of QoS (ie 802.1p, WMM, DSCPs, etc) we also have to coordinate all the moving parts including applications, network elements, etc and make them sing together. Even once we get everything just perfect, over time we see configuration drift and eventually we are back to square one. I will be covering more on this in an upcoming slide and our demo BYOD lack the awareness to do the right things for real-time media sessions. The Wi-Fi characteristics for running real-time media is vastly different then running data. We see all kinds of issues with BYODs and mainly because the Wi-Fi drivers lack the knowledge to know when an active voice or video stream is active. Coupled with the fact that there is no way for an application to communicate with the Wi-Fi driver via the OS this becomes even more problematic. We need a way to program a device when a real-time media session is active to do the right things. More on this in a later slide As stated before, many poor calls are the results of network issues. In fact greater then 60% of poor UC end-user QoE is due to the network. We have to move to a better and more cost effective method of making UC and networks work better together
- #4 So we took SDN and brain stormed what if an end user application like UC could program the network. What if the application layer that was traditionally relegated to orchestration and virtualization was UC centric also. Since UC real-time media flows or sessions can last from minutes to hours we saw them as long lived flows that were perfect to programing the network. We asked what if we could provide an out-of-band web service that informed the SDN controller of the start and end of a call and if the call was experiencing quality degradation due to network defects such as packet loss, jitter and delay. So we did just that and developed a REST based API and started to work with partners in evolving this vision. We started to work with vendors for all kind of scenarios and wanted to evolve SDN past the data center into Wi-Fi, campus, WAN and even LTE.