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.
OpenShift Commons Paris - Choose Your Own Observability Adventure
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
3. What is UC SDN
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 2018 forecast 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
6. Dialog
Event
UC
SDN
Interface
Events:
• Quality Update
event for 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
event for 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
10. International
Multimedia
Teleconferencing
Consortium (IMTC)
WebRTC
CTI
SIP
Telepresence
Media Relays
UC SDN 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
Notes de l'éditeur
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
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.