IntroductionParts I, II and III of this four paper series detailed how software-defined networking (SDN) and network functions virtualization (NFV) are enabling a more flexible networking architecture compared to traditional approaches that use fixed-function network elements. They also described high-level hardware and software requirements for the SDN architecture, relevant Intel reference designs, and ongoing efforts to make the orchestration layer better informed about node platform capabilities.

This paper, Part IV, focuses on the benefits L4-L71 deep packet inspection (DPI) brings to network operators and suggests OpenFlow* enhancements to take greater advantage of DPI technologies. After reading the paper, one will be able to explain how service-aware networks will enable new revenue opportunities and describe where DPI is likely to be deployed in SDN-based networks.

Network Operator ChallengesNetwork traffic is growing rapidly, as indicated by a 13-fold increase in global mobile data traffic forecasted over a seven year period.2 This is creating a critical business challenge for network operators: how to best address this traffic growth by building out infrastructure in a way that does not outpace the revenue generated by the services deployed on the infrastructure. This can be accomplished by improving bandwidth management, spending less on equipment, and deploying new profitable services more quickly – all facilitated by SDN architecture.

SDN makes it easier to manage bandwidth by giving operators the ability to manage network assets from a central control point with a global view instead of a decentralized, local view. This is because SDN architecture separates control and data plane functions within a network device, allowing traffic to be controlled with greater automation, more intelligence, and less support effort. Moreover, network functions run on industry-standard servers that typically have lower capital and operating expenses (CapEx/OpEx) than purpose-built network elements. Complexity is also reduced when network functions run on a common hardware platform, making it easier and faster to launch new services.

Another challenge facing network operators is insufficient knowledge about the traffic on their networks, much of which is third-party applications and services. Consequently, it is more difficult to enforce policy, manage traffic, and differentiate services, among other things. Today, SDN implementations are limited to L2-L4 headers, and as a result, switches cannot differentiate traffic from various L7 applications. This leads to the inefficient use of both network bandwidth and compute resources since each specialized system, like media servers, has to analyze all the traffic in order to pick out just the relevant flows (e.g., streaming video) and then process them.

Service-Aware Network Architecture Based on SDN, NFV, and Network IntelligencePart IV of series discusses how deep packet inspection (DPI) enables network operators to offer new services and better manage bandwidth by providing real-time visibility into IP traffic patterns and user behavior.

DPI gives operators greater control over networks carrying

traffic for a wide range of services and applications.

WHITE PAPERIntel® Architecture ProcessorsQosmos* DPI Technology Networking and Communications

Figure 1. Qosmos* ixEngine* generates various types of network intelligence.

L4-L7 DPI fills this gap by providing the network application and metadata information required for more intelligent decision-making. Later in this paper, there is a discussion about ways to expand DPI visibility in the OpenFlow protocol, allowing any network device to redirect application flows to specialized services of value to operators or end users. This is the basis for a service-aware network architecture designed to provide operators more control over their networks through improved policy control, video optimization, load balancing, firewalling, network monitoring, and more.

L4-L7 DPI and Network IntelligenceL4-L7 DPI creates the network intelligence that gives network operators the much-needed awareness of traffic flows. One such solution is Qosmos* ixEngine*, software used to analyze traffic flows and identify various attributes, including:

• Application ID: SIP, SMTP, YouTube*, Facebook*, BitTorrent*, Skype*, etc.

• Extracted metadata: URL, file name, browser type, cookies, DNS queries, video codec, IMSI, SIP caller/callee, user ID, login, etc.

• Computed metadata: Delay, jitter, application response time, etc.

Metadata is either extracted from the traffic or computed, and then it is used to generate statistics or criteria for rules. The rules may be proactive, meaning the node (e.g., switch) takes action without involving the SDN controller (based on a pre-configured policy), or reactive, as when the controller issues instructions back to the node.

Qosmos ixEngine can identify over 2,000 protocols and applications, and extract thousands of metadata types as shown in Figure 1. It is a software development kit (SDK) composed of software libraries and tools that are easily integrated into new or existing solutions. The architecture allows new applications to be identified when they arise through easy in-field updates. The software analyzes traffic in real time at 10, 40, 100 gigabits per second (Gbps), thus is able to support a wide range of applications, including traffic shaping, subscriber analytics, quality of experience (QoE), and cybersecurity.

Running on Intel® Xeon® processor-based platforms, Qosmos ixEngine can be deployed in dedicated network intelligence appliances or in virtual machines. This flexibility enables network operators to migrate their existing appliances to SDN and NFV networks at their own pace. Similarly, Qosmos DPI can be integrated in a physical or a virtual switch.

McAfee*

Skype*

Oracle*

VWware*

eBay* Yahoo!*

AIM*

Facebook*PDF

BitTorrent*

Gmail*

Visibility on thousands of application protocols

Embedded DPI& Network Intelligence

Extraction of 6,000+ MetadataCaller, called party, jitter, packet loss, latency,call duration, setup time, codec, throughput,mobile ID (IMSI, IMEI), phone number, userlogin, IP address, MAC address, date & timeof login / logoff, subject of email / chat /Webmail, sender, receiver, attacheddocuments, response time, data transfersessions (type, content, time), visitedWebsite, page content, time spent on visit,basket share, referent, etc.

Solutions embedding Qosmos*

2

PART IV: Service-Aware Network Architecture Based on SDN, NFV and Network Intelligence

Figure 2. DPI capacity scales up and out with Qosmos* ixEngine*

Figure 3. Traffic shaping enables network operators to deliver multi-tier QoE

Qosmos ixEngine has been optimized by using the Intel® Data Plane Development Kit (Intel® DPDK), proven to dramatically speed up packet processing on Intel® processors – by up to 10 times3 –compared to standard implementations. It shares a flow table with the Intel DPDK and fills in information indicating the protocol and application ID of each flow. The first packet of every flow is inspected, but for some flows like video, it is not necessary to inspect the other packets, which allows the Intel DPDK to use fast–path processing for the rest of the flow and thereby, speeds up transmission.

Scalability

Taking advantage of the capabilities of multi-core Intel processors, Qosmos ixEngine “scales up” by running on an unlimited number of virtual CPUs, depending on the hypervisor characteristics. What this means is network operators can increase the DPI load on a single node by increasing the number of virtual CPUs assigned to Qosmos ixEngine, as illustrated in Figure 2. The hypervisor would then be responsible for assigning the appropriate physical resources to support the number of virtual CPUs requested. Qosmos ixEngine also “scales out” DPI capacity through the addition of node substantiations, which provides unlimited scalability. Both scale up and scale out options can be implemented dynamically, giving network operators a high degree of flexibility in cloud-like fashion.

Virtual CPUs

Scale Up

ScaleOut

SoftwareGuest OS SoftwareGuest OS

Software

SoftwareGuest OS

Virtual Machine Virtual Machine

Multi-core Intel Processor®

Hypervisor

NetworkApplication

Virtual NetworkFunction

Qosmos*ixEngine*

Guest OSGuest OSSoftwareGuest OS SoftwareGuest OS

Software

SoftwareGuest OS

Virtual Machine Virtual Machine

Multi-core Intel Processor®

Hypervisor

NetworkApplication

Virtual NetworkFunction

Qosmos*ixEngine*

Guest OSGuest OSSoftwareGuest OS SoftwareGuest OS

Software

SoftwareGuest OS

Virtual Machine Virtual Machine

Multi-core Intel Processor®

Hypervisor

NetworkApplication

Virtual NetworkFunction

Qosmos*ixEngine*

Guest OSGuest OS

Revenue OpportunitiesNetwork operators can use L7 intelligence to create new or improved revenue-generating services. Once a traffic flow is identified by its application, or even by its individual subscriber, network operators can perform traffic shaping (Figure 3) based on the flow’s priority. This type of policy management is viewed by network operators as one of the effective and viable means to manage network traffic and promote revenue growth. This capability is well-established and deployed in the fixed-line networks that historically had the greatest data bandwidth demand. However, with the advent of smartphones, tablets, and other wireless connected devices, mobile networks are increasingly facing a similar challenge.

DataPlaneTraffic

Other

P2P

Email

VoIP

IM

Web

Video

L4-L7 DPI:Protocol andApplication

Identification

TrafficSteering

P2P

VoIP

Web

Metadata can also be used for non-traffic management applications, such as by retailers who want to engage mobile subscribers in a personalized way. Network operators can charge retailers for the information they collect (e.g., IP-based services by mobile user and transaction) with DPI in a radio access network (RAN) serving a store or point location. This information could allow retailers and businesses to provide a host of revenue-generating services, including:

• Proximity location – tell businesses where consumers are and where they are going in the surrounding area.

• Customer analytics – provide businesses data on how often customers are in the shop and how long they stayed when visiting.

• Customer locate – notify an advertiser when a customer is about to enter the mall so a targeted advertisement can be played for him/her on digital signage nearby.

3

PART IV: Service-Aware Network Architecture Based on SDN, NFV and Network Intelligence PART IV: Service-Aware Network Architecture Based on SDN, NFV and Network Intelligence

Figure 4. SDN and NFV architecture can simplify DPI deployments

• Personalized loyalty program – send a deal to the phone of a customer walking up to a store.

• Promotions – send maps and tourist promotions to the phone of a customer walking in an airport or entering a hotel.

• Engage customers – load sports clips to user phones in real time in a sports bar.

DPI in SDN ArchitectureThe traditional method for deploying DPI is to embed it in various network appliances and devices, such as a session border controller (SBC), traffic detection function (TDF), gateway GPRS support node (GGSN), and so on, as shown in the left side of Figure 4. A major drawback of this approach is the high cost associated with implementing DPI technology many times on different, non-commodity hardware platforms. In addition, the interworking between applications is difficult since each vendor may have a specific way of performing DPI and formatting the results. For instance, one vendor may classify a flow as Twitter while another vendor may designate it social media.

With SDN and NFV, DPI can migrate from being embedded in many network appliances to becoming a shared function hosted on standard servers (right side of Figure 4). This approach lowers the total investment in DPI, since DPI is implemented on fewer machines (less CapEx), and therefore less energy (OpEx) is consumed. Moreover, the interworking between different functions and applications using DPI is less complex because it is easier to enforce a consistent format for App IDs and metadata. With SDN/NFV, DPI is unlikely to reside where it currently is: in dedicated appliances or blades, in the GGSN, or in specific products like probes.

SessionBorder

Controller(SBC)

GatewayGPRS

Support Node(GGSN)

GGSNSBC TDF

Virtual Machines

DPIEngine

DPIEngine

DPIEngine

DPIEngine

TrafficDetectionFunction

(TDF)

Standard, High-Volume Servers and Switches

THE WIND RIVER* INTELLIGENT NETWORK PLATFORM INTEGRATES QOSMOS* DPIEquipment manufacturers building network elements for SDN and NFV can easily add greater network intelligence and new services to a virtualized environment by running Wind River* Intelligent Network Platform (INP). It is a comprehensive solution for the consolidation of management and data plane network applications, and contains important run-time components for data plane applications. INP integrates Qosmos* DPI to offer enhanced flow analysis and application identification coupled with pattern matching and accelerated network protocols. Operating separately or together to enable a network application running in a VM, there are three engines in INP:

• Wind River Flow Analysis Engine: Based on the Qosmos ixEngine*, this set of software libraries and tools enables deep visibility into layers 4–7 traffic flows, facilitating real-time packet classification, traffic categorization and communication protocol identification, among other network applications.

• Wind River Application Acceleration Engine: This comprehensive, optimized network stack accelerates Layer 3 and 4 network protocols, networking applications and security components.

• Wind River Content Inspection Engine: This high-speed engine matches large groups of regular expressions against blocks or streams in systems requiring deep packet inspection (DPI), such as intrusion prevention (IPS), antivirus (AV) and unified threat management (UTM).

4

PART IV: Service-Aware Network Architecture Based on SDN, NFV and Network Intelligence

Figure 5. DPI capacity scales up and out with Qosmos* ixEngine*

Locating DPI in SDN-based Networks As described in the first white paper of this series, SDN architecture consists of four or more layers,4 including the orchestration, business applications, control, and node layers. Figure 5 shows the three layers where DPI is likely to be embedded for traffic shaping, subscriber analytics, QoE, and cybersecurity, just to name a few. These deployment scenarios allow DPI information to be shared in the network, which saves CPU and energy costs as application recognition is done once instead of several times. Unified DPI simplifies management because all devices would share a “similar view” of the traffic. A major benefit of having the infrastructure provide DPI services is application developers no longer need to incorporate DPI themselves – there is no need to reinvent the wheel.

Business Applications

Northbound API

Southbound API

e.g., OpenFlow*,Open vSwitch*

Controller

NetworkAppliances

CloudServers

Switch MediaGateways

C-RANEPC

Orchestratore.g., OpenStack*

Node

Controller

NodeNodeNodeNodeNode DPI

DPI

DPI

The three probable deployment scenarios are described in the following:

Business applications layer

With relative ease, DPI software can be embedded in the business application layer. However, some application redesign may be needed to minimize the impact of potential bottlenecks created by a lengthy communication path. For instance, some of the traffic flows must be transmitted from the node – through the SDN controller – to the business application running a DPI engine. After the flow is identified, the application sends policy rules to the node to steer the flow, so only a fraction of the traffic is typically sent from the node to the network application.

Given the possibility for delay, this DPI deployment works best for non-time-critical network applications, like analytics.

Controller layer

DPI software may be deployed in the SDN controller, which may use the network intelligence for its own control services or send it to the network applications layer via the northbound API. The node (e.g., switch, network device) handling the flow sends the first non-empty packet to the SDN controller for L4-L7 analysis, possibly using the OpenFlow protocol with some extensions that are discussed at the end of the paper. Locating DPI in the controller avoids an increase in the cost of nodes; however, portions of the traffic (possibly less than 10 percent) must be duplicated and forwarded from nodes to the controller, which could lead to scalability and performance issues. A distributed controller architecture design can minimize these concerns.

Node layer

Network nodes can also run DPI software, and after identifying the App ID and metadata, they can either:

• apply a pre-defined policy directly, or

• send this information to the SDN controller or a network application, and then receive back policies or rules.

When the SDN controller is the recipient of the extracted information, it can instruct the node to apply a particular policy after having some sort of dialog with a network application. Afterwards, all subsequent flows of the same type do not require DPI analysis. Compared to the other options, implementing DPI in the node layer minimizes latency; then again, this approach is the costliest because it requires the largest number of DPI instances in the network. In the future, the number of DPI instances may be reduced by using methods for tagging or conveying DPI information in an end-to-end manner, as suggested in a recent draft IETF recommending enhancements by adding a Network Service Header (NSH).5 Some workarounds are also envisioned using tagging/labeling, tunnel configuration, etc., as suggested by the IETF Service Function Chaining Working group.

DPI in Open vSwitch*When developing software for switches – physical or virtual – one option is to deploy Open vSwitch*, a production quality, multilayer virtual switch licensed under the open source Apache 2.0 license. Open vSwitch can operate both as a soft switch running within the hypervisor or as the control stack for switching silicon. The software has been ported to multiple virtualization platforms and switching chipsets.6

5

PART IV: Service-Aware Network Architecture Based on SDN, NFV and Network Intelligence

Figure 7. The Intel® ONP Server Reference Design provides the basis for a virtual switch

Intel DPDK: Intel Data Plane Development Kit® ®

Software

PacketProcessing

Application 1

Virtual Machine

Software

Virtual Machine

SoftwareNetwork

Application

Software

Virtual Machine

Open vSwitch* accelerated with the Intel DPDK

Multi-core Intel Processor®

Wind River* Open Virtualization Profile

Wind RiverIntel Third PartyQosmos

OpenStack* Node Agent

Qosmos* ixEngine*

Intel DPDK: Intel Data Plane Development Kit® ®

Software

SoftwareGuest OS

Virtual Machine Virtual Machine

Open vSwitch* accelerated with the Intel DPDK

Vendor 1Application

PacketProcessing

Application 2

GuestOperatingSystem

GuestOperatingSystem

Intel DPDK(optional)

®

Intel DPDK(optional)

GuestOperatingSystem

Multi-core Intel Processor®

Wind River* Open Virtualization Profile

Wind RiverIntel Third PartyQosmos

OpenStack* Node Agent

Vendor 2Application

Virtual NetworkFunction

Virtual Machine

Qosmos*ixEngine

Guest OS Guest OS

Intel DPDK(optional)

®Intel DPDK

(optional)

®

Intel DPDK(optional)

®

Intel DPDK(optional)

®

Figure 6. Qosmos* ixEngine* can be integrated in Open vSwitch*

VirtualMachine 1

VirtualMachine 2

VirtualMachine n

Hypervisor

Virtual Server

Traffic

Flow Table

5 Tuple Application

Qosmos* ixEngine*L4-L7 Nework Intelligence

OpenvSwitch*

TrafficSlot

Integrated DPI Technology

With the addition of Qosmos ixEngine, Open vSwitch can also analyze traffic flows, as illustrated in Figure 6. This gives Open vSwitch visibility to:

• East-West traffic for virtual IP communications

• North-South traffic for communications with the physical network

• the App ID and metadata from traffic flows

Virtual Switch Reference DesignDesigners of DPI-enabled virtual switches can dramatically reduce development time by using the Intel® Open Network Platform Server Reference Design (Intel® ONP Server Reference Design). Included is a reference implementation of a high performance version of Open vSwitch, accelerated by the Intel DPDK and compatible with nearly any Intel Xeon or Intel® Core™ processor-based hardware platform. The reference design can also run Qosmos ixEngine, either integrated in the Open vSwitch software or in a virtual network function (VNF), as illustrated in Figure 7. Wind River* Open Virtualization Profile and Intel® Virtualization Technology (Intel® VT)7 provide a flexible, high performance and robust virtualization environment. For some workloads, the use of I/O Virtualization (such as PCI-SIG Single Root (SR-IOV), input/output memory management unit (IOMMU) or NIC network partitioning functionalities) could be used to provide direct access to virtual appliances.

6

PART IV: Service-Aware Network Architecture Based on SDN, NFV and Network Intelligence

Accelerated packet forwarding The consolidation of data and control planes on a general-purpose processor has been significantly advanced by the Intel DPDK, which greatly boosts packet processing performance and throughput. Pre-integrated in Wind River Linux*, the Intel DPDK provides Intel® architecture-optimized libraries to accelerate L3 forwarding, yielding performance that scales linearly with the number of cores, in contrast to native Linux. The solution is supported by the Wind River development environment, further simplifying use and code debug.

The Intel DPDK contains a growing number of libraries whose source code is available for developers to use and/or modify in a production network element. Likewise, there are various use case examples (e.g., L3 forwarding, load balancing and timers) that help reduce development time. The libraries can be used to build applications based on “run-to-completion” and/or “pipeline” models, enabling the equipment provider’s application to maintain complete control.

Importance of standardization SDN architecture enables the central control of network functions, and when applied to DPI, this capability facilitates the sharing of network intelligence. When the same DPI and L4-L7 intelligence is required by various network functions (e.g., video optimization, policy control, load balancing, firewalling, etc.), performing DPI once and using the results many times increases computing efficiency and reduces latency.

But currently, it is difficult to configure switches and optimize cross-application interaction due to inconsistent App ID and metadata formats. Therefore, L4-L7 App ID and metadata

should be standardized and structured as unified, homogeneous resources so each SDN function can use them. For SDN architecture, DPI and L4-L7 intelligence is standardized by the L4-L7 Study Group within the ONF Market Education Committee. DPI and L4-L7 intelligence have been approved by the ONF MEC as viable use cases to be considered in the Openflow specifications, and the Technical Architecture/Extensibility working groups are currently defining the associated reference designs and standards.

OpenFlow* Extensions Needed For L4-L7 Devices Qosmos is making proposals to enable OpenFlow, a south bound protocol, to carry extracted and computed metadata per flow between switches and SDN controllers. This additional L4-L7 intelligence would take the form of extensions to the existing OpenFlow protocol beyond the user-configurable n-tuple. These new “L4-L7 DPI” fields could become common format, used by all switches, controllers, and applications.

This could be achieved with a type-length-value (TLV) element incorporated in the OpenFlow protocol to support the encoding of optional information, such as the following fields.8

• Rules: identification of protocols, applications (App ID), and metadata

• Actions: such as drop the packet, encapsulate and forward the packet to the controller, or forward packet to port

• Statistics: including computed metadata, HTTP host-name, HTTP cookie, and vendor-specific attributes (VSA)

Figure 8 shows how the App ID, metadata fields, and actions could be added to the OpenFlow protocol.

Figure 8. OpenFlow* could be extended to better support DPI technology

InPort

VLANID

Ethernet

SA Type

IP

Protocol Src port Dst portDA SA DA

TCP Application

Metadata1

Rule Action Statistics

OpenFlow Flow Table Entry

Metadata2

1 2 3

1 Extend flow to include application data, as shown below:

2 Add actions, such as:1. Forward packets to ports2. Encapsulate and forward to controller3. Drop the packet4. Send to normal processing pipeline

3 Add new categories of statistics, such as computed metadata

Metadata2

7

PART IV: Service-Aware Network Architecture Based on SDN, NFV and Network Intelligence

Service-Aware Network ArchitectureNetwork operators deploying SDN and NFV-based networks can take advantage of the network intelligence delivered by DPI to offer new services and better manage bandwidth. DPI gives operators more control over their networks by helping them identify and supervise the wide range of services and applications they carry. This is achievable with computing and DPI technologies from Intel and Qosmos, respectively, who have developed a reference platform designed to accelerate the development of networking equipment supporting SDN and NFV. DPI will enable controllers and applications to make smarter decisions, creating cost-saving and revenue-generating opportunities for network operators.

For more information about DPI technology from Qosmos, visit www.qosmos.com.

For more information about Intel solutions for communications infrastructure, visit www.intel.com/go/commsinfrastructure.

PART IV: Service-Aware Network Architecture Based on SDN, NFV and Network Intelligence

1 L4-L7 refers to Layers 4 though 7 defined in the Open Systems Interconnection (OSI) model. 2 Source: “Cisco* Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2012–2017,” February 6, 2013. http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/

ns827/white_paper_c11-520862.html. 3 Sources: http://www.6windblog.com/6winds-support-for-high-performance-networking-using-the-intel-dpdk and http://www.advantech.com/products/FWA-6510/mod_de4e7263-371d-4973-9b2f-

0c59905d92d0/CaseStudies/%7B800105F0-43E2-48F8-8464-BE80FB874A9 and http://www.adlinktech.com/PD/web/PD_detail.php?cKind=&pid=1239&PHPSESSID=080d4a5ea4d0306c80fbf636aafae450.

4 There may be many more layers in a deployment scenario that integrates with existing systems. 5 Source: http://tools.ietf.org/html/draft-quinn-nsh-00. 6 Source: http://openvswitch.org. 7 Intel® Virtualization Technology (Intel® VT) requires a computer system with an enabled Intel® processor, BIOS, virtual machine monitor (VMM), and for some uses, certain platform software

enabled for it. Functionality, performance, or other benefits will vary depending on hardware and software configurations and may require a BIOS update. Software applications may not be compatible with all operating systems. Please check with your application vendor.

8 Source: “L4-L7 In SDN-OpenFlow Networks Requirements Brief,” generated by the Market Education Committee (MEC) of Open Networking Foundation (ONF).

Copyright © 2014 Intel Corporation. All rights reserved. Intel, Xeon, Intel Core, and the Intel logo are trademarks of Intel Corporation in the United States and/or other countries. *Other names and brands may be claimed as the property of others. Printed in USA 0114/MS/TM/PDF Please Recycle 329290-002US