DPI in an SDN world Charles Glass

Abstract SDN brings the promise of agile and elastic networks. DPI vendors have been quick to embrace SDN, and African operators are already benefiting. Traditional DPI platforms were built on custom hardware and remain largely proprietary. The need for better network visibility, subscriber traffic management and QoE led to the proliferation of DPI. Until recently focus for SDN has been on Layers 2-3, Layers 4-7 and indeed DPI will become a critical focus for the future.

DPI seeks to make the network application-aware, while SDN seeks to make applications network-aware (Heavy Reading, 2012) Google Searches by Topic SDN DPI has been widely deployed. Our experience spans almost 5 years in sub-Saharan Africa working with. We have worked with 5 of the major service providers in the region. Operators are focusing on the use cases DPI can address rather than the underlying technology. New use cases are emerging and there are some great examples in Africa. DPI

What is DPI? DPI helps operators regain control over a network that is now primarily carrying third-party applications and services, by accurately identifying those applications in real time. (Heavy Reading, 2012) For this presentation we are referring to DPI as used by operators to identify, manage and report on applications traversing the network. Vendors include Ipoque, Qosmos, Citrix, Sandvine, Allot, Procera and Cisco Source: Online-edge

DPI High-level Architecture Control Layer Data Layer Load balancing Inspection Enforcement Management Source: Cisco

What is SDN? The physical separation of the network control plane from the forwarding plane, and where a control plane controls several devices. (Heavy Reading, 2012) Application layer A development has rapidly emerged out of enterprise and academic environments, called software-defined networking (SDN). SDN aims first to separate out all network "control" functions from the simple data forwarding function in network switches and routers, and enable the network to be treated as a programmable resource. Though the two (DPI and SDN) developments are unrelated, they have similar objectives http://www.qosmos.com/wp-content/uploads/2013/03/Heavy_Reading-Qosmos_DPI-SDN-WP_Dec-2012.pdf Control layer Infrastructure layer Source: Network Computing

High-level SDN Architecture Application Layer Control layer Infrastructure layer Management Source: ONF

Build-up to SDN DPI NFV Network Virtualisation Will it still be relevant? Where will it be located? NFV Complementary to SDN Encourage virtualisation of network functions DPI a strong candidate for virtualisation Network Virtualisation In its more radical variants, SDN brings revolutionary change to network architectures, raising questions about where capabilities such as policy, security and DPI will be located, and what they are for. In particular, will the current use cases for DPI still be relevant in a fully-developed SDN environment? And how can vendors and users of DPI prepare for SDN, given that the timing of SDN remains vague? Meanwhile, a network operator initiative called Network Functions Virtualization has been launched with aims that are complementary to the ONF's. As the name implies, its aim is to encourage the virtualization of a wide range of network functions to reduce equipment and power costs and improve service velocity. http://www.qosmos.com/wp-content/uploads/2013/03/Heavy_Reading-Qosmos_DPI-SDN-WP_Dec-2012.pdf

Bridging the gap Core concepts in todays networks Policy DPI SDN focused on Layers 2-3 How do we bridge the gap? Core current concepts such as load balancing, Layer 4-7 switches, policy management and application delivery controllers (ADCs) – which rely on a deep, real-time insight into higher layers that identifies applications and other metadata on traffic – are likely to play an even bigger role in an SDN network than they do today. As things stand, however, there is no clear guidance yet from the ONF on how this gap is to be bridged. http://www.qosmos.com/wp-content/uploads/2013/03/Heavy_Reading-Qosmos_DPI-SDN-WP_Dec-2012.pdf

Will operators still need DPI? Fundamentals of DPI have not changed Identify traffic in real-time Associate with other data Subscriber Location Device DPI and related techniques will be at the heart of that transformation. It will create a virtuous circle or feedback loop in which a stream of real-time information on performance, application use trends, user behavior, congestion events, device trends and much else besides is fed back to the SDN controller and to the various network and consumer applications connected to it. Using policy and related tools (e.g., optimization software), this will allow for continual adjustment to circumstance, optimizing both the efficiency with which resources are consumed and the quality of the end-user experience – goals that match the ultimate aims of SDN, as well as closely related developments such as virtualization DPI-like capabilities will be used to feed a rich stream of information to the big data analytics packages that are more and more important to telcos as they seek to gain an understanding (increasingly automated) of what end-users are doing, and shape service offerings accordingly. QoE has moved rapidly up the operator agenda in the past one to two years, but a QoE dashboard is only as good as the information fed into it. http://www.qosmos.com/wp-content/uploads/2013/03/Heavy_Reading-Qosmos_DPI-SDN-WP_Dec-2012.pdf

SDN Applications Applications in SDN need a complete view of the network DPI could feed information to the controller? Killer app for DPI? One critical aspect in all of this is that the applications and associated control elements need a holistic view of infrastructure conditions. This is a central goal of the ONF SDN plan, and something that DPI, in principle, can provide, by gathering information throughout the network and feeding it back to the control layer (controller) and to the applications so as to ensure that the right resources and capabilities are made available. This may turn out to be the killer app for DPI http://www.qosmos.com/wp-content/uploads/2013/03/Heavy_Reading-Qosmos_DPI-SDN-WP_Dec-2012.pdf

Locating DPI in an SDN Collocated with network devices In the controller Collocated with controller Extensions to the flow table to include an application ID In an SDN, DPI could potentially be collocated with network devices (e.g., as software running in virtual switches), or it could be in the control layer (e.g., in the controller that mediates between applications and switches). In principle, collocating DPI capability in switches would be a more efficient way to run DPI, especially in view of the high CPU resource requirement. One way in which this information might traverse the network is as an extension to the flow table, as described in the next section. Application management systems could then extract relevant information to make real-time service decisions. In principle, this functionality could also be standardized, at least up to a point. http://www.qosmos.com/wp-content/uploads/2013/03/Heavy_Reading-Qosmos_DPI-SDN-WP_Dec-2012.pdf

Benefits for African Operators DPI components are being virtualized in the build-up to SDN NFV is the main driver Early days? Benefits Simpler deployment, update and testing Scale to changing workloads Lower cost Reduced complexity Open standards

Industry View DPI SDN Use cases Some large deployments.. Not so many.. African Operators Industry view Use cases: Gaming bolt-on by Vox, Telkom night surfer and Afrihost’s turbo-button. Econet Zimbabwe’s free facebook and later WhatsApp packages.

Q&A Source: Cisco blog – Stephen Spiers http://blogs.cisco.com/datacenter/sdn-adoption-challenges-my-wrap-up-for-2013