A Sandvine Technology Showcase

Contents

Executive Summary ................................... 1

Introduction ............................................ 2

Network Policy Control and Network Functions

Virtualization ....................................... 2

Network Functions Virtualization Benchmarks

and Milestones ...................................... 3

Building a One Terabit per Second Policy Control

VNF ...................................................... 4

Components ......................................... 4

Configuration .................................... 5

Testing ............................................... 6

Achieving Sufficient Load ...................... 7

Ensuring a Realistic Test ....................... 7

Results ............................................... 8

Performance Scale ............................. 10

Performance Efficiency ....................... 11

Conclusions ............................................ 13

Optimizations and Extensions ................... 13

Related Resources................................. 14

Invitation to Provide Feedback ................. 14

Executive Summary This document explains how Sandvine, Dell®, and Intel®, using

standards-based virtualization technologies, have achieved data

plane performance scale and efficiency within a policy control

virtual network function (VNF) that exceeds those of proprietary

network appliances.

Data Plane Inspection Throughput: 1.1 Tbps (using

realistic traffic, including diverse protocols,

encapsulation and tunneling)

Rack-Space: 10 rack units (RU) (includes all compute,

storage, and network components)

Peak Power Consumption: 4995 W

Performance Density: 110 Gbps/RU

Power Efficiency: 4.5 W/Gbps

These figures are all superior to those provided by network

appliance vendors, and should effectively put to rest any

concerns or questions surrounding the practical and commercial

viability of network functions virtualization for policy control use

cases.

This demonstration proves that network functions virtualization

is a cost effective alternative to proprietary network appliances,

and that virtualized policy control deployments can meet the

scale, efficiency, and business objectives of communications

service providers.

Breaking the Terabit Barrier: A One Terabit per Second Policy Control Virtual Network Function

A 1 Tbps Policy Control VNF

Page 2

Introduction Traditionally, the processing demands of network policy control (e.g., stateful packet processing,

complex decision-making, etc.) required proprietary hardware solutions, but technology advances

mean that virtualization now provides a commercially viable alternative.

Transitioning from a purpose-built, proprietary hardware component – a model in which a vendor likely

controls every aspect – to a virtualized commercial off-the-shelf (COTS) model is a formidable

challenge. In the latter model, performance is dependent on various network elements and compute

node density, and drivers and data plane acceleration capabilities vary by hardware manufacturer. We

have previously discussed these challenges in Implementing Policy Control as a Virtual Network

Function: Challenges and Considerations.

This document explains how Sandvine, Dell, and Intel have achieved a major performance milestone: a

single policy control virtual network function (VNF) that delivers 1.1 Tbps of data policy control

throughput, with a compact rack-space footprint and exceptional power efficiency.

Network Policy Control and Network Functions Virtualization Network policy control (also called policy management) refers to technology that enables the definition

and application of business and operational policies in networks.

Network policy control works by:

identifying conditions (e.g., subscriber entitlement, current network conditions, data traffic

identity, etc.);

evaluating decisions (e.g., determining if the network is congested, deciding whether certain

traffic constitutes a distributed denial of service attack, etc.); and

enforcing actions (e.g., record the usage into a database, decrement from a prepaid wallet,

mitigate attack traffic, manage congestion, etc.).

Policy control powers many innovative subscriber services, network management actions, and business

intelligence (e.g., big data, customer experience management, analytics, etc.) initiatives.

Network Functions Virtualization (NFV) is a carrier-led effort to move away from proprietary hardware,

motivated by several desires:

1. To increase agility and enable faster service launches

2. To reduce operational costs by leveraging elastically scalable, API-driven architectures: in an

NFV environment, software applications performing network functions share execution,

storage, and network resources, and these resources can be turned on and off as needed

3. To reduce capital costs by harmonizing on COTS hardware: by using standard x86 COTS

hardware for everything – that is, by running all vendor solutions on a common hardware

architecture – an operator needs fewer spare parts, can standardize the provisioning systems,

lower their operational expenditure, and can simplify their supply chain

Oftentimes, it is assumed that virtualizing a network appliance may lead to greater operational

budgets in the data center due to larger footprint demands and the use of less efficient hardware

components than those found within specialized network appliances.

But is this really the case? This paper proves otherwise.

A 1 Tbps Policy Control VNF

Page 3

Network Functions Virtualization Benchmarks and Milestones With any new technology wave, there is a gradual progression from a theoretical foundation, to proving

fundamental concepts (e.g., functional interaction, performance explorations, etc.), and finally to

demonstrations of commercial practicality. From there, chasms are crossed and the technology is

adopted until it eventually becomes ubiquitous wherever practical.1

Virtualization for network policy control functions is no exception:

In May 20132, Sandvine teamed up with Heavy Reading to explore some of the theoretical issues

around software-defined networking and NFV in a joint whitepaper Policy Control & SDN: A

Perfect Match? In the press release announcing the paper, Sandvine stated that, “Some

technical details will need to be worked out. Traffic needs to be steered in and out of the

network functions cloud with full subscriber, state and resource capacity awareness. To

provide a consistent level of service to subscribers on a per-session basis requires session-

aware load balancing, or partitioning, across resources.”

In October 20133, Sandvine became the first network policy control vendor to demonstrate a

completely virtualized solution, at the SDN & OpenFlow World Congress

In February 20144, Sandvine announced a business services offering based on a virtualized

policy control platform5

In July 20146, the Sandvine Virtual Series had been deployed by a number of CSPs

Up to this point, the commercial deployments were relatively smaller scale, with customers deploying

the Sandvine Virtual Series in locations with relatively low data plane throughput requirements and for

which high-scale proprietary equipment was not economical.

With functionality proven, the next wave of benchmarks and milestones dealt with performance.

In March 2015, a Sandvine blog post, “The PTS Virtual Series: Virtualized Performance in the

Real World,”7 detailed how the PTS Virtual Series had achieved 155 Gbps in a single system Dell

PowerEdge R730x with Intel Xeon® E5-2699 v3 processors

This was an important milestone, as it showed that virtualization could deliver the same performance

density, at scale, as proprietary equipment.

However, real-world carrier deployments often demand many hundreds of gigabits per second of

performance. To achieve this scale, many hardware elements must be clustered and load-balanced

together, cooperating to achieve the singular objective of implementing network policy control.

It is this performance milestone – a policy control VNF of several hundred Gbps – that remained

uncrossed…until now.

The remainder of this paper will explain how this milestone was achieved, including the equipment

used, the configuration parameters, and the nature and results of the performance tests.

1 Referring of course both to the technology adoption lifecycle and Geoffrey Moore’s adaptation in Crossing the Chasm. 2 The announcement can be found here. 3 The announcement can be found here. 4 The announcement can be found here. 5 The Cloud Services Policy Controller, which subsequently won the Network Appliances category at the Intel Network Builders

Network Transformation Contest. 6 The announcement can be found here. 7 The blog post can be found here.

A 1 Tbps Policy Control VNF

Page 4

Building a One Terabit per Second Policy Control VNF The subsections below explain the components, configuration, and test methods used to establish this

performance benchmark.

Components Table 1 details the components that were used to implement the virtualized deployment.

Table 1 - Solution Components

Component Description/Notes

Sandvine Policy Traffic Switch Virtual Series v7.20

The virtualized version of Sandvine’s Policy Traffic Switch (PTS).

In a policy control deployment, the PTS performs three critical functions: traffic classification, policy decision-making, and policy enforcement.

The PTS Virtual Series uses the Intel DPDK v2.1.0 API8.

1x Dell PowerEdge9 M1000e10 blade enclosure

The PowerEdge M1000e blade chassis enclosure is the robust foundation for the PowerEdge M series blade solution, enabling significant data center density, with power and cooling efficiency, on a platform that is easy to deploy and manage. Includes:

Redundant Chassis Management Controller (CMC)

6x3000 W capable AC Power Supply Units (PSU)

6x Dell Networking Force10 MXL11 switches

Ethernet switches provide multiple converged 10GbE interface data transfers in M1000e blade deployments and a range of 40GbE data transfers North/South of the enclosure.

The six MXL units provide a total complement of 192x10GbE switch ports for blade server interconnect and 36x40GbE for top-of-rack connectivity.

For this test, 112 of the available 10GbE switch ports were used by the PTS Virtual Series data plane.

14x Dell PowerEdge M63012 blades

Half-height, two-socket 13th-generation blade servers, with:

2x Intel Xeon Processor E5-2699 v3 18-core CPUs

1x Intel X71013 4x10GbE Network Daughter Card (NDC)

2x Intel X54014 2x10GbE Mezzanine Card

64GB RAM

120GB SSD

Although two Xeon processors are populated, one was disabled for this test; importantly, this means that there is substantial room for growth in higher-complexity work per packet.

8 More information is available here. 9 More information is available here. 10 More information is available here. 11 More information is available here. 12 More information is available here. 13 More information is available here. 14 More information is available here.

A 1 Tbps Policy Control VNF

Page 5

All blades’ host operating system run the Intel Open Network Platform (ONP) v1.4 Server Software15 reference compute node configuration, which is based on Fedora 21 Server, with the following software versions:

Linux: Kernel v3.17.8-300.fc21.x86_64

QEMU-KVM: v2.1.3-8.fc21

Libvirt API: v1.2.9.3

Note that two of the M1000e half-height server slots remain unused (see Figure 1), allowing expansion or for use of control-plane or reporting components.

Figure 1 shows the populated Dell PowerEdge M1000e.

Figure 1 - Front (left) and back (right) view of the populated Dell PowerEdge M1000e; note the two empty

half-height slots visible in the front view.

Configuration Each PTS Virtual Series guest instance was deployed on the Dell PowerEdge M630 Servers as a single

virtual machine, using one socket. The other socket was not used, leaving room for future expansion.

Eight 10GbE interfaces were used across 4 bridge groups (4x2 10GbE) for data plane inspections to each

of the 14 Dell PowerEdge M630 blade servers.

The eight Intel 10GbE Converged Network Interfaces per server were assigned to the guest VNF via PCI

Passthrough using the Linux VFIO kernel module.

On each blade, only one of the two available Xeon processor sockets had its 18 physical cores pinned as

virtual CPUs (vCPUs) to the guest instance virtual machine. NUMA cell integrity was preserved between

CPU and NIC mapping. The remaining Xeon processor socket remained idle and running the Host Fedora

OS specified in Intel Open Network Platform (ONPv1.4) Server Software.

15 More information is available here.

A 1 Tbps Policy Control VNF

Page 6

16GB of the available 64GB of each host RAM was assigned to the guest PTS Virtual Series instance.

Each PTS Virtual Series instance includes different network components within its running functions to

perform different tasks, including:

PTS Module (PTSM): traffic forwarding and encapsulation support

PTS Daemon (PTSD): application detection and enforcement

Load Balancer: one such instance is typically configured per bridge group and load balances the

traffic to a PTSM and PTSD pair via a virtual NIC, maintaining session awareness and preserving

processing core affinity

For the purpose of the virtual configuration, we have pinned the guest vCPU (which are host physical

cores):

1 vCPU for each Load Balancer process; 4 vCPU in total

1 vCPU pair for each PTSM/PTSD process pair; 7 pairs in total, for 14 vCPU

The vCPU allocation as represented from the PTS command line:

PTS> show system cpu allocation

NumberOfVCPUs : 18

NumberOfInspectionInstances: 7

NumberOfLoadBalancers : 4

Figure 2 - Inside a PTS Virtual Series instance

Testing Table 2 details the components that were used to test the solution.

Table 2 - Test Components

Component Description/Notes

1x Dell PowerEdge R730

Rack server to function as a traffic generator, equipped with:

1x Intel X710 4x10 GbE NIC

6x Intel 82599ES 2x10 GbE NIC

DPDK pktgen traffic generator16

Traffic generator powered by Intel’s DPDK.

An application packet payload functionality was added to the traffic generator software by Sandvine.

16 More information about pktgen is available here.

A 1 Tbps Policy Control VNF

Page 7

Achieving Sufficient Load To sustain traffic across all 14 PTS Virtual Series instances, a novel traffic generation approach was

used.

Traffic patterns from the R730 traffic generator were encapsulated into a GRE tunnel. Since the PTS

Virtual Series has inspection support for a multitude of tunnel types, including GRE, the traffic will be

inspected within the tunnel (i.e., preserving application awareness).

Tunnel broadcasting17 is employed to have the packet stream traverse the bridge groups of all PTS

Virtual Series instances. While not a true IP broadcast, this method employs Non Broadcast Multicast

Address (NBMA) as an outer Destination IP address for the GRE tunnel endpoint, and is used in some

VPN deployment methods.

To complement this approach, the Dell Force10 MXL switches were configured to operate in Layer 2

mode, with their IGMP snooping capability disabled. This configuration causes the L2 domain to flood

the multicast stream to all the switch VLAN member interfaces, essentially replicating the multicast

traffic of each individual stream (which in this scenario is a GRE-encapsulated payload) across the 14

interfaces connected to the PTS Virtual Series’ bridge ports.

By replicating this configuration across all legs of the bridge ports (i.e., eight in total), the test

platform generates 80 Gbps of traffic from the R730 traffic generator, across eight 10GbE interfaces,

each of which being a multicast source to one of eight VLANs on the MXL switches, which are each in

turn mapped to a bridge port of a PTS.

Ultimately, this approach transforms each source of 10 Gbps traffic stream generation into 80 Gbps of

traffic input into the Force10 MXL, which subsequently forwards the multicast across all VNF bridge

ports of the 14 PTS instances. The total traffic forwarded across the six Force10 MXLs and through the

single PTS VNF thus totals 1,120 Gbps (80 Gbps times 14 instances).

Ensuring a Realistic Test To have practical relevance in the real world, the test must be as realistic as possible. An important

element of realism is the actual traffic that is passed through the PTS Virtual Series VNF.

In order to generate a real packet payload across all bridge groups of the PTS Virtual Series cluster and

to require use of the PTS Virtual Series’ rich traffic classification capabilities, the DPDK pktgen

software was employed and its traffic “Range” function was used to generate a valid range of IP

traffic:

IP ranges: 254 different Source and Destination address increments in each of eight streams

TCP port ranges: 254 each of Source and Destination increments in each stream

Packet payload sizes: a range of packet payload size sweep, from 400 to 1518 bytes, to allow

for real life application payload insertion18

Different start point of each port, IP address and packet size in each stream

Applications: A per-thread iteration of multiple applications from four application categories

(Real-Time Entertainment, Social Media, Peer-to-Peer, and Web Browsing)19.

17 Explained somewhat here: http://linux-ip.net/gl/ip-tunnels/node9.html 18 If the reader is looking for exclusively 64-byte packet performance, then it is sufficient to examine DPDK performance alone,

as there would be no payload. Such performance information is available here. 19 These four categories typically account for more than 80% of all Internet traffic. Check out Sandvine’s Global Internet

Phenomena Reports for detailed statistics.

A 1 Tbps Policy Control VNF

Page 8

Putting it all together, the traffic flowing through the PTS Virtual Series bridge groups consisted of:

An application payload, within

An IP TCP packet with SRC and DST port and IPv4 address sweeping through 254 possible values,

within

An IP type 47 GRE packet, with

An IPv4 multicast destination address and valid IPv4 source address, with

An 802.1q VLAN ID with static value per port, within

An L2 datagram with a Source MAC corresponding to the NIC in use, and Destination Multicast

Ethernet address

Figure 3 shows a Wireshark capture of a 1000-byte test packet.

Figure 3 – Wireshark capture of a test packet

For the sake of clarity, the description above omits other standard fields that were present in the

traffic, such as Preamble, Ether Types, and CRC/FCS,

To further test the PTS Virtual Series under realistic conditions, a number of instances were configured

with GRE tunnel awareness (i.e., were configured to inspect within the tunnel itself), while others

were left with a default configuration where the GRE tunnel was the expected traffic detection result

(i.e., the traffic classification processes would not look within the tunnels).

Results We confirmed that the traffic generation from pktgen was at line-rate, from both the generator host

and the Dell Force10 MXL switch port interface statistics. Each reported valid/expected data:

Multicast packets being received

Interface Bitrate (excluding pre-amble and packet gap): input 9818.00 Mbps per 10GbE

Packet rate: 1271245 packets/s

Switch port capacity: 99.90% of line-rate

Note that the same interface statistics were observed on each of the 112 10GbE switch ports of the

MXL switches.

On the PTS VNF, the individual interface groups were observed to bridge the incoming traffic:

PTS> show interface rate

DATA INTERFACES

===============

Port In(bps) Out(bps) PacketsIn(pps) PacketsOut(pps)

----- ------- -------- -------------- ---------------

1-3 9.79G 9.79G 1.26M 1.26M

1-4 9.79G 9.79G 1.26M 1.26M

A 1 Tbps Policy Control VNF

Page 9

1-5 9.79G 9.79G 1.26M 1.26M

1-6 9.79G 9.79G 1.26M 1.26M

1-7 9.79G 9.79G 1.26M 1.26M

1-8 9.78G 9.78G 1.26M 1.26M

1-9 9.79G 9.79G 1.27M 1.26M

1-10 9.78G 9.78G 1.26M 1.27M

TOTAL 78.30G 78.30G 10.10M 10.10M

The CLI command output of the interface rates above represent the 8x 10GbE Ethernet interfaces as

data ports available on each instance of PTS Virtual Series.

The PTS Load Balancer module handles traffic from each of the four bridges per PTS, and balances the

traffic via the virtual NIC across the seven processing vCPU pairs (i.e., a pair consisting of one PTSM

and one PTSD process).

The traffic balancing was confirmed:

PTS> show interface rate lb

Port In(bps) Out(bps) PacketsIn(pps) PacketsOut(pps)

-------- ------- -------- -------------- ---------------

lb0.ptsm 0.00 19.49G 0.00 2.52M

lb1.ptsm 0.00 19.50G 0.00 2.53M

lb2.ptsm 0.00 19.50G 0.00 2.52M

lb3.ptsm 0.00 19.49G 0.00 2.53M

TOTAL 0.00 77.98G 0.00 10.10M

PTS> show interface rate module

Port In(bps) Out(bps) PacketsIn(pps) PacketsOut(pps)

-------- ------- -------- -------------- ---------------

ptsm0.lb 10.82G 0.00 1.40M 0.00

ptsm1.lb 10.82G 0.00 1.40M 0.00

ptsm2.lb 10.82G 0.00 1.41M 0.00

ptsm3.lb 10.82G 0.00 1.39M 0.00

ptsm4.lb 10.83G 0.00 1.41M 0.00

ptsm5.lb 10.81G 0.00 1.39M 0.00

ptsm6.lb 10.84G 0.00 1.42M 0.00

TOTAL 75.76G 0.00 9.83M 0.00

Note that the throughput and packet rates vary across all tables, due to the varying packet sizes, gap,

preamble, and payloads.

With default payload detection enabled, each PTS Virtual Series instance showed the following traffic

classification within each tunnel:

PTS> show traffic

ApplicationType SessionRate Downstream(bps) Upstream(bps) Total(bps)

--------------------- ----------- --------------- ------------- ----------

Tunneling 0.00 37.59G 37.58G 75.17G

Miscellaneous 0.00 0.00 0.00 0.00

RealTimeEntertainment 0.00 0.00 0.00 0.00

A 1 Tbps Policy Control VNF

Page 10

PeerToPeer 0.00 0.00 0.00 0.00

WebBrowsing 0.00 0.00 0.00 0.00

Email 0.00 0.00 0.00 0.00

RealTimeCommunication 0.00 0.00 0.00 0.00

BulkTransfer 0.00 0.00 0.00 0.00

Gaming 0.00 0.00 0.00 0.00

NetworkStorage 0.00 0.00 0.00 0.00

SocialNetworking 0.00 0.00 0.00 0.00

TOTAL 0.00 37.59G 37.58G 75.17G

When GRE tunnel inspection was enabled, each PTS Virtual Series instance showed the following traffic

classification:

PTS> show traffic

ApplicationType SessionRate Downstream(bps) Upstream(bps) Total(bps)

--------------------- ----------- --------------- ------------- ----------

WebBrowsing 0.00 9.29G 9.70G 18.99G

RealTimeEntertainment 0.00 9.86G 8.90G 18.76G

SocialNetworking 0.00 8.66G 9.97G 18.63G

PeerToPeer 0.00 9.66G 8.89G 18.55G

Miscellaneous 0.00 0.00 0.00 0.00

Email 0.00 0.00 0.00 0.00

RealTimeCommunication 0.00 0.00 0.00 0.00

BulkTransfer 0.00 0.00 0.00 0.00

Tunneling 0.00 0.00 0.00 0.00

Gaming 0.00 0.00 0.00 0.00

NetworkStorage 0.00 0.00 0.00 0.00

TOTAL 0.00 37.47G 37.46G 74.93G

The delta between traffic rates without and with GRE inspection enabled is because the payload rate

reported in the latter configuration excludes all encapsulation, preamble, and CRC/FCS prior to the

inspected and counted payload.

Performance Scale Aggregating the results shown above (i.e., the 78.30Gbps traffic rate) across all fourteen PTS Virtual

Series instances totals to 1.096 Tbps (excluding preamble) observed at the PTS bridge groups.

The PTS Virtual Series VNF performed policy control (i.e., real-time traffic inspection and

classification) on IP payload for 1.052 Tbps and 1.049Tbps, respectively, for GRE level detection and

GRE-aware application inspection.

For all test iterations, the total aggregated throughput measured at the Dell Networking Force10 MXL

Ethernet switch including preamble and packet gaps was 1.1 Tbps.

Figure 4 shows the PTS Virtual Series deployment as viewed in Sandvine’s Control Center policy and

operations management graphical user interface. Of particular note:

The navigation pane (on the left) shows all 14 PTS Virtual Series instances

The Flow Capture pane (bottom-middle) shows a real-time snapshot of the flows traversing the

system

The Statistics pane shows the real-time packet and byte rates

A 1 Tbps Policy Control VNF

Page 11

Figure 4 - Control Center screen showing the aggregate deployment

Performance Efficiency Scale without efficiency is insufficient, so how did this demonstration fare in terms of efficiency, and

how does the achieved efficiency compare to existing commercial network policy control appliances?

Throughout the functional tests, the Dell PowerEdge M1000e Chassis Management Controller was polled

for its Power Budget and Power Management environmental metrics. These values were polled via the

Dell CMC CLI racadm getpbinfo and racadm getpminfo commands:

The total server power budget during the test peaked at 4995 W for the Server infrastructure;

average power consumption was ~3500 W

The remaining chassis power budget (MXL switches, Fans, KVM, and chassis control functions)

peaked at 1420 W

Combining the achieved scale with the observed power consumption (and using the peak power to keep

things conservative), we see that compute node power efficiency is an impressive 4.5 W/Gbps of policy

control function.

These values compare very favorably (see Figure 5, Figure 6, and Figure 7) to competing hardware

appliance vendors in the network policy control space: other policy control vendors who have pursued

an appliance-based solution deliver best-case scenario performance between 8.3 W/Gbps and 16.2

W/Gbps, depending upon the vendor and the particular appliance, with variable maximum scalability.

For the sake of comparison, these figures also include the PTS 32000, a two rack unit 100 GbE unit

capable of intersecting 400 Gbps.

A 1 Tbps Policy Control VNF

Page 12

Figure 5 - Performance cost, in terms of power consumption per unit of performance

Figure 6 - Performance efficiency, in terms of throughput per unit of power consumption

Figure 7 – Performance density, in terms of throughput per rack unit

3.8 4.5

8.3

16.2

02468

1012141618

PTS32000

PTSVirtual Series

CompetitorAppliance A

CompetitorAppliance B

Watt

s /

Gbps

Performance Cost

260

220

120

62

0

50

100

150

200

250

300

PTS32000

PTSVirtualSeries

CompetitorAppliance A

CompetitorAppliance B

Mbps

/ W

att

Performance Efficiency

187.5

110

43 36

0

50

100

150

200

PTS32000

PTSVirtualSeries

CompetitorAppliance A

CompetitorAppliance B

Gbps

/ R

U

Performance Density

A 1 Tbps Policy Control VNF

Page 13

Conclusions This demonstration proves that network functions virtualization is a cost effective alternative to

proprietary network appliances, and that virtualized policy control deployments can meet the scale,

efficiency, and business objectives of communications service providers.

Table 3 - Summary of Benchmarks

Metric Performance

Data Plane Inspection Throughput 1.1 Tbps

Rack-Space 10 rack units (RU)

Power Consumption 4995 W

Performance Cost 4.5 W/Gbps

Performance Efficiency 220 Mbps/W

Performance Density 110 Gbps/RU

These figures are all superior to those provided by network appliance vendors, and should effectively

put to rest any concerns or questions surrounding the practical and commercial viability of network

functions virtualization for policy control use cases.

Optimizations and Extensions It is worth noting that the four PTS Load Balancer instances ran at an average of 70% CPU usage per

instance; this means that at 20 Gbps full line rate on the bridge group, a single physical Xeon core can

handle the packet forwarding rate with cycles to spare, as is often demonstrate by Intel DPDK packet

forwarding benchmarks.

Additionally, each PTSM/PTSD pair ran at an average of 57% CPU usage per instance. Importantly, this

result means that there is still significant capacity within the pairs to carry out additional policy

control functions well beyond identifying and measuring traffic in real-time (e.g., network security,

online charging, etc.).

This CPU utilization also demonstrates that we could have delivered even more impressive power

efficiency, had we elected to use five PTSM/PTSD pairs per PTS Virtual Series instance (which could

have been accommodated by the remaining CPU capacity) instead of the seven that we used in the

test. This configuration would have freed up four physical cores and their associated power, per PTS

Virtual Series instance, from the overall power budget.

However, we instead chose to implement as realistic a test as possible, as a genuine proof of the viable

economics of virtualized policy control solutions, rather than to slant the configuration to deliver an

even more favorable (but less representative) result.

Additionally, as noted in Table 1, although two Xeon processors are populated, one was disabled for

this test; like the 57% CPU utilization, this means that there is substantial room for growth in higher-

complexity work per packet.

A 1 Tbps Policy Control VNF

Page 14

Related Resources In addition to the extensive list of footnotes included within this document, readers interested in

virtualization and specific use case reference implementations should visit https://nfv.net/, the online

home of the NFV Leaders Forum.

Invitation to Provide Feedback Thank you for taking the time to read this technology showcase. We hope that you found it useful, and

that it helped you understand how we, together with Dell and Intel, achieved this important

performance milestone.

While this paper is fairly technical, it is not meant to be a complete reference publication of the

metrics, configuration, and procedures used for the demonstration. Readers interested in more detail

are encouraged to contact Sandvine.

If you have any feedback or have questions that have gone unanswered, then please send a note to

whitepapers@sandvine.com

Copyright ©2015 Sandvine

Incorporated ULC. Sandvine and

the Sandvine logo are registered

trademarks of Sandvine Incorporated

ULC. All rights reserved.

European Offices

Sandvine Limited

Basingstoke, UK

Phone: +44 0 1256 698021

Email: sales@sandvine.co.uk

Headquarters

Sandvine Incorporated ULC

Waterloo, Ontario Canada

Phone: +1 519 880 2600

Email: sales@sandvine.com