5 guidelines for DPI development and deployment

Karl Wale, Director, Product Line Management, Radisys -July 02, 2014

Here are some ideas on how to navigate deep packet inspection (DPI) solutions in a network functions virtualization (NFV) and software defined networking (SDN) world. 

Deep packet inspection (DPI) as a technology has evolved. Originally, it served as a core technology in the net neutrality debates, with applications and equipment used to identify “bad” bandwidth-hogging media streams and punish the subscribers. Today, DPI has more positive connotations, focusing on network service assurance to ensure that the network understands the type of traffic being carried and delivers the appropriate bandwidth. Now, the type of traffic is the key, not the content.

DPI deployment is also being re-visited in relation to software defined networking  (SDN) and network functions virtualization (NFV) initiatives. To provide context relative to DPI, let’s recap SDN and NFV.  

SDN transforms the way that networks are managed, controlled, and used. It takes the router function and separates its role into two parts, decoupling the control plane and the data plane. The high-bandwidth data plane remains on the hardware platform, while the control plane (routing protocols, intelligence) is centralized. OpenFlow, or similar software protocols, provides a north-south connection between the control plane and data plane.

NFV promises operators a faster service roll out, along with improved capital and operating expense savings. NFV is designed to allow a common pool of compute and network resources to run virtualized instances of services or applications, providing high density and highly elastic capabilities. This increased elasticity can help accelerate the roll-out of new services from weeks or months to just days.

Impact of SDN and NFV
Many applications that leverage DPI technology deliver service assurance or network optimization. Application examples include policy and charging enforcement function (PCEF), video optimization, Internet offload, and other platforms (see Figure 1).

These devices are often deployed on the Gi LAN (between xGSN/LTE packet gateway and the Internet). The Gi LAN is one of the first areas that operators expect to virtualize, and introduces new buzz words for DPI on the Gi LAN: multi-tenancy and service chaining.

FIGURE 1: DPI related products on Gi LAN.

Today, the platforms that employ DPI are often discrete devices. Each device contains a load balancer working in conjunction with DPI to identify the traffic, along with a number of service blades that run the application (video compression, forwarding, policy, quality of service, etc.) Multi-tenancy can be achieved by taking virtual versions of these devices (most vendors have a virtual version of their product) and running them on a common set of resources (pizza box servers, blade servers such as standardized ATCA, or proprietary implementations) as illustrated in Figure 2. Although multi-tenancy requires qualification and integration, it allows an operator to quickly roll out new capabilities, assuming the hardware resources are in place within the data center or central office and there is suitable connectivity to the network.

FIGURE 2: Virtualization and multi-tenancy

Beyond multi-tenancy, the goal of DPI also includes service chaining. In a typical Gi LAN deployment, virtualized or not, every packet passes through every function, which is an inefficient use of computing and network resources. Centralizing the application identification with an intelligent load balancer at the entry to the Gi LAN service layer will allow traffic to be sent only to where it is best utilized (see Figure 3). For example, video will be sent to video compression, but web or other traffic would bypass this device.

While this leads to higher efficiency on the network and processor usage, it also creates more complexity. This provides a snapshot of the future needs that operators must consider when creating DPI systems for NFV and SDN enabled carrier networks.

FIGURE 3: Service chaining in virtualized platform

DPI relies on inspecting a sequence of packets related to a given flow, such as a user’s video or web session, in order to make a determination about the type of traffic being carried (video, email, voice, P2P, gaming or other). In order to do this inspection, every packet related to that session must be identified, load balanced, and forwarded consistently to the same blade, processor, core and thread running the application. This is flow affinity.

Flow affinity is one of DPI’s founding principles, but performance is challenged. Typically,  standard switch silicon is not capable of handling the multiple tunnels, tags, and labels in IP headers found in today’s networks to effectively parse and isolate the packets and load balance them to target CPU resources. DPI vendors have previously overcome this issue by using dedicated CPU blades; however, our research indicates that if load balancing is implemented in a standard x86 server, up to one-third of the compute resource might be used for load balancing traffic. This quickly becomes cost and space prohibitive.

Now consider a large centralized set of DPI applications providing Gi LAN services. These applications may have to handle several hundred Gb/s of traffic, including support for 100GbE network interfaces off the local edge routers. When coupled with the load balancing challenge, the traffic far exceeds the capabilities of commercial servers today, unless they are augmented by specialized network devices to terminate and load balance traffic on their behalf.

DPI vendors also face the challenge of tracking millions of user sessions. Today, network traffic levels are expanding dramatically, and a typical smart phone can have 10 to 15 sessions active at one time. This means that systems may need to track and load balance hundreds of millions of flows simultaneously while dealing with potentially millions of new connections per second.

The goal of the DPI industry is to use centralized orchestration layers with open-source initiatives, such as OpenStack and OpenFlow. This presents a new challenge as these protocols are not designed to handle these massive flow tables or the associated high update rates.

If the Gi-LAN is to be virtualized to support multi-tenancy and service chaining, a hybrid approach will be required to balance the goal of centralized orchestration with the practical requirements of tracking and updating hundreds of millions of unique flows, while keeping up with line rate traffic and not dropping packets.

Loading comments...

Write a Comment

To comment please Log In