Having previously tested and validated Nokia's IP Routing and Mobile Gateway VNFs, independent test lab EANTC evaluated the vendor's virtualized Broadband Network Gateway (BNG) and Application Assurance (AA) network functions -- here's what happened.

March 22, 2016

28 Min Read
Evaluating Nokia's VNFs: Part 2

Whether a network function is deployed on a dedicated hardware platform or as a virtual network function (VNF), communications service providers (CSPs) need to be sure they are going to get a certain level of performance at real-world operational scale: "Carrier grade" is not optional -- it's a must have.

So as CSPs start to introduce VNFs into their next-generation network rollout plans, one of the main questions they'll be asking as their vendor partners offer virtual alternatives to traditional bespoke boxes is -- can VNFs achieve carrier-grade performance levels?

That's why Light Reading's independent test lab partner, EANTC, has focused on performance and scalability during its recent evaluations of a number of Nokia VNFs.

Earlier this year, Light Reading published a test result report following EANTC's evaluation of Nokia's Virtualized Service Router (VSR) and Virtualized Mobile Gateway (VMG): They key takeaway from that set of tests was that Nokia has a set of VNFs that not only passed EANTC's exacting tests, but passed with flying colors across a variety of scenarios. (See Validating Nokia's IP Routing & Mobile Gateway VNFs and EANTC Tests Nokia IP Routing & Mobile Gateway VNFs for Real World Deployment.)

Now the EANTC team has revisited Nokia's labs in Mountain View, California, to test two more of the vendor's VNFs, both of both of which run on Nokia's VSR.

Figure 19:

The virtual Broadband Network Gateway (VSR-BNG), which plays an important role in subscriber management and the delivery of multimedia services to residential broadband users, and virtualized Application Assurance (VSR-AA), which performs a number of deep packet inspection (DPI)-related tasks, were both put through their paces to see if they could stand up to the production network performance and scalability standards expected by CSPs.

As you'll see on the following pages -- which provide a detailed explanation of the tests, how they were set up and the outcomes -- the VSR-BNG and VSR-AA met the brief in terms of throughput, subscriber load, redundancy (in multiple potential downtime scenarios) and feature functionality.

The key takeaway is that CSPs can be confident that these VNFs are ready to move out of the lab and proof of concept setup and into the network as part of a next generation, cloud-oriented transformation: Network functions virtualization is ready for prime time.

The following pages tell the story of the multiple tests undertaken by the EANTC team:

Page 2: Introduction, Executive Summary and Test Highlights
Page 3: Nokia Virtualized Service Router — Broadband Network Gateway (VSR-BNG): The Test
Page 4: Test results: VSR-BNG — Lifecycle Management
Page 5: Test results: VSR-BNG — Scalability and Performance
Page 6: Test results: VSR-BNG — Multi-System Redundancy
Page 7: Nokia Virtualized Application Assurance (VSR-AA): The Test
Page 8: VSR-AA -- Scalability and Performance Tests
Page 9: VSR-AA – Features and Functionality

We also now have a single PDF document that pulls together the full range of Nokia VNF tests undertaken by EANTC: That document can be accessed by clicking on this link.

— The Light Reading team and Carsten Rossenhövel, managing director, European Advanced Networking Test Center AG (EANTC) (http://www.eantc.de/), an independent test lab in Berlin. EANTC offers vendor-neutral network test facilities for manufacturers, service providers, and enterprises.

Introduction, Executive Summary and Test Highlights
Light Reading commissioned EANTC to verify the functionality and performance of Nokia's virtualized Broadband Network Gateway (BNG) and Deep Packet Inspection (DPI) solutions.

Our tests included the Nokia Virtualized Service Router for virtual Broadband Gateway (VSR-BNG) and virtualized Application Assurance (VSR-AA) network functions.

We validated the performance, scalability and high availability of Nokia's solutions in realistic test scenarios. Our team developed a detailed, reproducible test plan and executed the tests on site at Nokia's labs in Mountain View, Calif.

The VSR-BNG and VSR-AA solutions extend Nokia's portfolio of virtualized network functions based on similar technologies, such as virtualized forwarding path (VFP) and symmetric multi-processing (SMP). These technologies are described in the previously released EANTC VSR-PE test report. (See Validating Nokia's IP Routing & Mobile Gateway VNFs.)

Executive summary
EANTC validated data plane and control plane performance of Nokia VSR-BNG, focusing on high throughput and subscriber scalability.

We also verified the solution's support for multi-system redundancy and measured the service failover time in case of a chassis failure.

We reviewed the provisioning process of the VSR-BNG and its management using the Nokia 5620 SAM (Service Aware Manager).

The Nokia VSR-AA demonstrated high throughput performance with up to 12 million concurrent application traffic flows in a realistic mix.

Test Highlights

  • Up to 31 Mpps (million packets per second) VSR-BNG throughput with 16,000 dual stack IPoE or a mix of 8,000 IPoE with 8,000 PPPoE subscribers; 79.2 Gbit/s (Gigabits per second) throughput with IMIX frames on a single-socket Intel Xeon E5-2699v3 CPU

  • Up to 128,000 single stack OR 64,000 dual stack IPoE subscribers with one egress queue and a policer per subscriber on VSR-BNG

  • VSR-BNG established single stack subscriber sessions at maximum rate of 2,000/s; dual stack subscribers at 800 sessions/s without session synchronization

  • VSR-BNG supported multi-system synchronization and maintained all sessions successfully in all node and link failure scenarios

  • VSR-AA supported up to 12 million concurrent flows and 36 Gbit/s realistic traffic on a single-socket Intel Xeon E5-2699v3 CPU

  • VSR-AA supported up to 290,000 new HTTP flows/s

Figure 18: Table 1: Hardware & Software Under Test

Next page: Nokia Virtualized Service Router — Broadband Network Gateway (VSR-BNG): The Test

Nokia Virtualized Service Router — Broadband Network Gateway (VSR-BNG): The Test

VSR-BNG: Test set-up
As the virtualization platform, Nokia used standard Supermicro servers running OpenStack Liberty. Nokia chose OpenStack over commercial virtualization infrastructure solutions to demonstrate the platform independency of the tested virtual network functions (VNFs).

VSR-BNG was provisioned on two Supermicro compute nodes, each with a dual-socket Intel Xeon CPU and four two-port Intel X520-2 10GbE (10 Gigabit Ethernet) cards.

One compute node served as a host for the VSR Data Path VMs (packet forwarding), running on a dual socket system using E5-2699 v3, where the VM was using only one socket. Another compute node hosted two control VMs (protocol handling and management), both running on a dual-socket Intel Xeon E5-2687W v3, where each control VM was hosted on a socket.

Figure 1 below shows the physical topology of a single VSR-BNG system.

Figure 1: Figure 1: Physical Test Setup VSR-BNG Figure 1: Physical Test Setup VSR-BNG

The actual VSR-BNG test scenarios were configured using two logical test topologies per different test areas, as shown in Figures 3 and 5.

For the VNF management and the lifecycle management, we used Nokia 5620 SAM (Service Aware Manager) software (v13.0 patch 6596). TiMOS-C-0.0.B0-4702 software version was used in all VSR-BNG tests.

For the throughput tests, we defined a traffic mix designed to resemble the typical Internet packet size mix ('IMIX') as specified in the table below. We tested a mix of IPv4 and IPv6 traffic in a 50:50 ratio.

Frame Size (Bytes)*

Proportion

66 (IPv4) or 86 (IPv6)

47.4% (18/38)

128

7.9% ( 3/38)

373

2.6% ( 1/38)

570

10.5% ( 4/38)

1280

13.2% ( 5/38)

1492

18.4% ( 7/38)

* Minimum PPPoE frame size was 70(IPv4) and 90 (IPv6)

Next page: Test results: VSR-BNG – lifecycle management

Test results: VSR-BNG — Lifecycle Management

  • Key Takeaway: Nokia successfully demonstrated lifecycle management support by the 5620 SAM VNF Manager, including instantiation, monitoring and alarms.

As the first step, we reviewed the process of the VNF onboarding and instantiation within the virtualization infrastructure for each VNF type.

Each VNF was represented in the catalogue as a Heat Orchestration Template (HOT), which defines the 'personality' of the VSR-BNG and the virtualization infrastructure requirements. The Heat environment file was also used to specify additional parameters, such as addressing, network ports and smbios configuration to define boot and slot parameters.

We performed the final configuration steps both on a physical Nokia 7750 SR router and on the VSR instance, using the same 5620 SAM as Element Management System (EMS). During all test steps, we monitored the alarms and other notifications displayed by the EMS, comparing them with the status of the actual network elements as accessible with OpenStack tools and CLIs. The 5620 SAM displayed all relevant alarms and notifications that we were looking for and was always in sync with the actual state of the VNFs (verified manually). As shown in Figure 2, the 5620 SAM was also able to manage and display all active subscriber parameters.

Figure 2: Figure 2: 5620 SAM EMS Manager - Active Subscriber Parameters Figure 2: 5620 SAM EMS Manager — Active Subscriber Parameters

By sending data traffic, we validated that all deployed VNFs functioned correctly.

It should be noted that all management operations could be performed using Nokia 5620 SAM, rather than using low-level OpenStack management tools.

Next page: Test results: VSR-BNG -- Scalability and Performance

Test results: VSR-BNG -- Scalability and Performance

  • Test highlights

  • VSR-BNG achieved 79.2 Gbit/s throughput with 16,000 subscribers and 48,000 queues and policers. Maximum latency was 32.1 ms, average 1.4 ms

  • VSR-BNG supported up to 31 Mpps throughput using 100 byte packet size Maximum latency was 5.8 ms, average 0.4 ms

  • VSR-BNG scaled up to 128,000 single stack sessions

  • Established single stack subscribers at 2,000 sessions/s and dual stack subscribers at 800 sessions/s

We deployed a realistic broadband access scenario by simulating a large number of IPoE and PPPoE subscribers. While the IPoE subscribers used DHCP and MAC-based authentication, the PPPoE ones were configured with CHAP authentication, all of which is typically seen in production networks. We verified separate and mixed IPoE/PPPoE scenarios. Each subscriber scenario was tested in an IPv4-only and in an IPv4/IPv6 dual-stack configuration. Nokia configured VSR-BNG to assign three IP addresses per subscriber for the dual-stack scenario: IPv4; Identity Association for Prefix Delegation (IAPD); and Identity Association for Non-temporary Addresses (IANA).

While dual-stack scenarios are more resource-consuming for the BNG than other IPv6 migration techniques, they simplify the IPv6 transition from the subscriber point of view.

The BNG configuration included a set of Quality of Service (QoS) configurations applied per subscriber representative for a realistic multi-service broadband access scenario, adding more intensive compute operation for the VSR BNG. In particular, we defined three ingress policers per subscriber, parented at two different levels, and three egress queues per subscriber, parented to a port scheduler; with classification being done based on DSCP marking.

In addition, we defined per-subscriber IP access-list with 100 entries in such a way that the test traffic had to be matched against each rule before being allowed to pass.

As shown in figure 3, the Ixia analyzer (emulating both subscribers and the Internet services) was attached to the DUT via a Nokia 7750 SR router, using four 10GbE links on both the subscriber and network side.

Figure 3: Figure 3: VSR-BNG - Physical Test Setup Figure 3: VSR-BNG — Physical Test Setup

For the multi-system redundancy setup, Nokia configured four VPLS instances at the subscriber/access side of the 7750 SR router. On the network-facing side, we configured OSPF with Equal Cost Multipath (ECMP) to distribute traffic over four physical links.

Finally, a single IP VPN was configured on the core 7750 SR to aggregate all traffic towards the emulated Internet. Armed with these generic configurations, the setup was ready for the actual performance tests.

VSR-BNG: Throughput Performance
We measured the throughput performance of the VSR-BNG by sending a 50:50 mix of IPv4 and IPv6 frames using IMIX frame sizes. Seven thousand emulated dual-stack subscribers transmitted three different classes of traffic (EF, AF and BE) on both ingress and egress direction forwarding traffic inside a total of 21,000 queues on egress and 21,000 policers on ingress. In addition, 9,000 dual-stack subscribers sent best-effort-only traffic on ingress and egress direction forwarding traffic inside a total of 9,000 queues on egress and 9,000 policers on ingress; Concurrently, a total of 30,000 active queues were served on egress and 30,000 policers were served on ingress.

The VSR-BNG achieved 79.2 Gbit/s throughput, close to the maximum line rate in this configuration (80 Gbit/s). The latency averaged at 1.4 ms and did not exceed 32.1 ms. In a second test run, we used a smaller packet size (100 bytes) to measure the highest packet rate per second: The VSR-BNG reached 31 million packets per second (Mpps). The latency was measured between 0.052 ms and 5.8 ms this time, averaging at 0.4 ms.

Although IPoE is becoming the prevalent broadband access protocol, PPPoE is still widely used. We confirmed the identical throughput performance for VSR-BNG when PPPoE was used in place of IPoE.

VSR-BNG: Subscriber Scalability
The throughput test showed that VSR-BNG can support 16,000 simultaneously active subscribers. Since each subscriber was configured with three egress queues and three ingress policers, VSR-BNG managed a total of 48,000 queues and 48,000 policer instances.

In this test case, we intended to increase the number of concurrent subscriber sessions to a total of 128,000. Nokia informed us about the current system limitation of 131,072 queues and 262,144 policers, which effectively prevented using multiple classes per subscriber with this number of sessions.

We performed two test runs, with 64,000 dual-stack and 128,000 IPv4-only IPoE sessions, but with only one queue and policer configured per subscriber. Both tests completed successfully and without any data loss, confirming Nokia's claims for subscriber scalability.

VSR BNG: Subscriber Session Setup Rate
Now that we had baselined data throughput and subscriber scale, we aimed to verify the BNG's ability to establish a large number of sessions at a high rate. This scenario is most relevant after a transport network failure causing a large amount of subscribers to reconnect to the BNG at the same time.

We configured the Ixia analyzer to establish IPoE sessions without retries and verified that a session establishment rate of 2,000 subscribers-per-second for a single-stack scenario and 800 subscribers-per-second for a dual-stack scenario (with DHCPv6 IA_NA and IA_PD allocations for IPv6) could be achieved without retries or session failures.

Session Type

DHCP server location

Total sessions

Setup Rate

IPoE single stack IPv4

On VSR-BNG

16,000

2,000

IPoE single stack IPv4

External

16,000

1,800

IPoE/PPPoE dual stack

On VSR-BNG

16,000

800

IPoE/PPPoE dual stack

External

16,000

800

IPoE single stack

On VSR-BNG

128,000

2,000

The setup rate was tested with a single VSR-BNG.

VSR-BNG: Quality of Service
EANTC had focused on QoS test scenarios already in the VSR-PE test session. At the access edge, proper prioritization and policing plays a major role. VSR-BNG implements policers, queues and shapers for each class while managing rates and congestion.

Since VSR implements all QoS functions in software, EANTC focused on the precision of the policing functions as well as their scale.

The number of sessions (16,000), three egress queues and three policers per subscriber were configured as before. Additionally, Nokia configured the egress queues to be parented to a port scheduler at two different scheduling levels and policers to be parented at two different levels; PIR (Peak Information Rate) was applied at different points, namely queues, port scheduler overall rate, per level rate on the port scheduler and rates on policers. Figure 4 depicts the configuration in detail.

Figure 4: Figure 4: VSR-BNG - QoS Deployment per Subscriber Figure 4: VSR-BNG — QoS Deployment per Subscriber

We sent traffic only for 2,000 of the 16,000 subscribers in this test, focusing on the port scheduler rate limiting, PIR per egress queue and ingress policer with rate limiting. The results were as expected; all flows sent to the 2,000 subscribers were policed and rate limited as configured.

Next page: Test results: VSR-BNG – Multi-system Redundancy

Test results: VSR-BNG — Multi-System Redundancy

  • Test highlights

  • In all node and link failure scenarios, VSR-BNG maintained all sessions successfully.

  • Data forwarding for all 16,000 sessions was recovered within less than 2.4 seconds for any failover scenario.

VSR-BNG implements multi-system redundancy to protect against link and node failure. A cluster of two BNGs contains an active and a standby unit. Nokia's Subscriber Router Redundancy Protocol provides synchronization of subscriber sessions between the active and the standby BNG instance, as shown in figure 5. In case of a failure, Nokia claimed that the standby node would be capable of taking over all active subscriber sessions without session loss and possibly only brief data traffic loss.

Figure 5: Figure 5: BNG Multi-System Redundancy Figure 5: BNG Multi-System Redundancy

For this test case, we configured a second set of two Supermicro compute nodes to host the Data Path and Control VMs of the standby instance. The standby instance used identical hardware, software and configuration as the active one.

We configured four SRRP instances on the subscriber access side, as well as four VPLS instances to provide connectivity to all four Supermicro chassis.

EANTC validated three failover scenarios:

  • Active Node failure

    • Link failure /SRRP session failure

    • Failure of a single Control VM instance within the chassis

      As before, 16,000 IPoE dual-stack subscriber sessions were set up, forwarding bidirectional traffic at a constant rate. To achieve better consistency of the results, each failover test was performed twice. Based on the packet loss occurring during the failover, we estimated the service interruption time.

      VSR-BNG: Active Node Failure
      The active node failure was simulated by issuing the admin reboot command on the active node CLI. As expected, the standby node took over the subscriber sessions and traffic. After the rebooted VSR-BNG node came back online, it assumed the active role again after a configured hold-time period (which was used to allow enough time for re-synchronization of subscriber states), since the redundancy was configured with the preemption option.

      As an alternative to the CLI-triggered failover, we also tested the node failure through power failure. We cut electrical power to the chassis running the control VMs of the primary node.

      In both cases, the VSR-BNG successfully detected a node failure and performed the failover, maintaining all active sessions. We measured a maximum of 731 ms data traffic loss (failover) and 2,400 ms (restoration) for all sessions.

      VSR-BNG: Link Failure
      We tested the ability of VSR-BNG to trigger a failover on a link failure by physically disconnecting one of the four SRRP-running links between the aggregation router and the multi-system BNG while having each SRRP instance tracking the state of the other SRRP instances on the node, causing all links to be fate-shared.

      As expected, the standby system took over the active role without losing any subscriber sessions.

      Failure scenario

      Traffic direction

      Service interruption time for failover in ms

      Service interruption time for restoration in ms

      Admin reboot of active VSR-BNG

      Access to Network

      Run 1: 244
      Run 2: 251

      Run 1: 1,604
      Run 2: 2,385

      Admin reboot of active VSR-BNG

      Network to Access

      Run 1: 731
      Run 2: 476

      Zero loss in both test runs

      Power failure of active VSR-BNG

      Access to Network

      Run 1: 355
      Run 2: 363

      Not tested

      Power failure of active VSR-BNG

      Network to Access

      Run 1: 407
      Run 2: 578

      Not tested

      Fail the link running SRRP

      Access to Network

      Run 1: 728
      Run 2: 582

      Run 1: 2,246
      Run 2: 947

      Fail the link running SRRP

      Network to Access*

      Run 1: 2,127
      Run 2: 1,378

      Zero loss in both test runs

      * High service interruption time observed for the subscribers belong to the disconnected link. We measured 13 ms maximum failover time on other three links.

      VSR-BNG: Control VM Failure
      In addition to the multi-system redundancy, we verified the redundancy of the control plane within a single chassis. VSR-BNG utilizes two Control VMs running on each unit.

      We simulated a failure of the active Control VM in two ways: first through a graceful shutdown via CLI command; and second, by a hard shutdown using OpenStack nova stop command.

      In the case of the graceful shutdown, we observed 1.16 ms service interruption in one of the test runs and no interruption when we used nova stop command.

      VSR-BNG: Data Path Link Failure
      Finally, we verified the function of the OSPF Equal Cost Multipath (ECMP) in case of a link failure.

      ECMP was configured on the network-facing links between the VSR-BNG and the 7750 SR router. The link state was monitored with BFD configured with a 150 ms timer. In case of the failure of one of the links, ECMP should be capable of redistributing the traffic to the remaining links after failure has been detected on one of the available paths.

      We physically disconnected one of the links to trigger the failure and reconnected it after some time to test the recovery. This procedure was performed twice. As expected the traffic was correctly redistributed between available links. We measured a maximum service interruption time of 289 ms.

      Next page: Nokia Virtualized Application Assurance (VSR-AA): The Test

      Nokia Virtualized Application Assurance (VSR-AA): The Test
      Nokia's VSR-AA implements Application Assurance functions. As Nokia explained, it uses deep packet inspection (DPI) to provide stateful L7 application identification and control.

      VSR-AA is integrated into the data path VM of the VSR platform and therefore can operate either as a dedicated function (VSR-AA) or as part of the data path for functions such as VSR-BNG, VSR-PE, Virtualized Mobile Gateway (VMG), without requiring the need for an additional VM, or traffic steering.

      Some of the typical use cases for the VSR-AA deployment are, according to Nokia:

      • Collection of application traffic statistics, application performance indicators, content charging data

      • Traffic control and rate limiting on a per-application/per time-of-day basis

      • In-browser notifications, URL blacklisting, URL whitelisting, parental control

      • Application-specific firewall

      As these functions are quite diverse, we focused testing the scalability and performance of VSR-AA. In addition we validated a number of key use cases.

      The VSR-AA test platform was configured as an integrated version of the VSR system, consisting of Control and Data Path components in a single VM. The VSR system was part of a DPI test setup that was provisioned manually on the servers (instead of using OpenStack). Nokia expected this to have no impact on the performance test results.

      We ran all tests on a Supermicro server; 18 cores were allocated to VSR-AA. In all tests, we used TiMOS-B-0.0.B0-4702 software.

      We used an Ixia Breaking Point System FireStorm One for generation and analysis of realistic application traffic.

      Figure 6: Figure 6: VSR-AA - Physical Test Setup Figure 6: VSR-AA — Physical Test Setup

      Figure 7: Figure 7: VSR-AA - Logical Test Setup Figure 7: VSR-AA — Logical Test Setup

      Next page: VSR-AA -- Scalability and Performance Tests

      VSR-AA: Scalability and Performance Tests
      We performed a series of baseline tests to determine the basic metrics of VSR-AA's performance:

      • Maximum session/flow capacity

      • Maximum traffic session/flow rate

      • Maximum data plane throughput

      VSR-AA was configured with 927 application classification rules and 50 policy control rules, such as applying DSCP classification for specific application traffic. VSR-AA was also configured to export per-subscriber application accounting statistics (xml format) as well as performance statistics and device information. The entire user traffic was diverted to the VSR-AA function for classification by defining a default app profile for all users.

      In total, we simulated 64,000 statically configured subscribers using one IPv4 address each and an application traffic mix as shown in the following figures.

      Figure 8: Figure 8: VSR-AA - Flow Distribution Figure 8: VSR-AA — Flow Distribution

      Figure 9: Figure 9: VSR-AA - Bandwidth Distribution Figure 9: VSR-AA — Bandwidth Distribution

      VSR-AA: Throughput Performance and Latency
      In order to verify the raw performance of the VSR system throughput with no DPI using this hardware platform, we first ran a reference throughput test with no AA function. This was achieved with a test configuration using 4x10GigE links processing through the VSR and not diverting the user traffic for AA DPI classification.

      Using an Ixia Breaking Point analyzer, we generated an application traffic mix and were able to achieve line rate performance (40 Gbit/s). The maximum frame latency was 0.40 ms, while the average TCP session setup time and average TCP response time were 0.4 ms and 0.2 ms respectively.

      With user traffic directed to the AA function, we achieved an average performance of 36 Gbit/s with 5.3 million concurrent TCP and 0.4 million UDP sessions. From AA's perspective, it handled up to 11.4 million flows.

      Figure 10: Figure 10: VSR-AA - Throughput Performance Figure 10: VSR-AA — Throughput Performance

      We also measured latency in this test. As Nokia expected, the latency at flow classification was higher, measuring at an average of 1.4ms for the TCP session setup due to the processing delay incurred during flow classification analysis: The first few packets in a new flow undergo more processing to classify them, which results in higher latency.

      Once VSR-AA had identified the flow and configured a rule for application-specific treatment, subsequent frames were forwarded with a much lower latency, similar to the one observed when the AA function was disabled. The figure below illustrates the concept. Due to limitations of the test equipment, EANTC was unable to validate precise details of latency over time.

      Figure 11: Figure 11: VSR-AA - Delay Measurement Figure 11: VSR-AA — Delay Measurement

      VSR-AA: Concurrent Flow Scalability
      In this test we verified the maximum number of concurrent flows that VSR-AA can support for traffic inspection.

      Initially, we established 5.525 million TCP connections plus 0.475 million UDP connections (representative for DNS traffic) and generated 36 Gbit/s traffic across VSR-AA. We verified that all flows were supported and processed by VSR-AA as expected.

      Then, as a follow-up step, we intentionally exceeded VSR-AA's design limit of around 12 million concurrent bidirectional traffic flows. The excessive flows were simply forwarded without any inspections or classifications. The CLI statistics on VSR-AA displayed these flows as an "unknown" application.

      VSR-AA: Maximum Flow Rate
      We measured the maximum transaction rate by sending HTTP GET requests/responses at a rate of 145,000 per second, with one HTTP transaction per TCP connection: VSR-AA supported up to 290,000 new HTTP flows per second (see Figure 13 below).

      Figure 12 below shows the measured TCP sessions setup rate on the traffic analyzer.

      Figure 12: Figure 12: VSR-AA - Maximum Setup Rate Figure 12: VSR-AA — Maximum Setup Rate

      Figure 13: Figure 13: VSR-AA - Maximum Transaction Rate Figure 13: VSR-AA — Maximum Transaction Rate

      Next page: VSR-AA – Features and Functionality

      VSR-AA – Features and Functionality
      We also evaluated the functional aspects of the VSR-AA and verified the precision with which it could handle test traffic in accordance with predefined rules.

      VSR-AA: Data Analysis Accuracy
      We evaluated the application-type detection accuracy by comparing the per-application statistics collected by VSR-AA with the traffic mix loaded by the Ixia emulator.

      As shown in Figure 14, VSR-AA was able to recognize the volume of the traffic with a high degree of accuracy, including being able to differentiate between various HTTP-based services.

      Figure 14: Figure 14: VSR-AA - Application Statistics Figure 14: VSR-AA — Application Statistics

      The measurement mechanisms of VSR-AA and Ixia differed, so the measurement precision was limited to 1.4% maximum measurement error.

      VSR-AA: Traffic Rate Limiting
      We verified the ability of VSR-AA to selectively rate-limit aggregated traffic on a per-application basis. For the purpose of the test, Nokia configured a profile for YouTube traffic that applied rate-limiting at 870 Mbit/s.

      Using the Ixia Breaking Point System, we generated an application traffic mix at 36 Gbit/s that included approximately 5.2 Gbit/s of YouTube traffic. With the rate-limiting profile applied, this traffic was reduced to 990 Mbit/s. The difference between 990Mbps and 870Mps is due to Breaking Point System measuring Ethernet (Layer 2) bandwidth while VSR-AA rate-limit controls traffic at the IP (Layer 3) level. Another factor to consider is that the traffic generator continuously sends a high rate of new, short-duration YouTube TCP sessions: These sessions are rate-limited after the TCP session establishment phase used for L7 application identification, while the test set calculates the average traffic rate across the entire TCP session.

      We repeated the test by applying an additional rate-limiting profile for the iTunes traffic: That test was equally as successful.

      VSR-AA: Features Demonstration
      We used a different, smaller Supermicro system with 10 CPU cores for the demonstration of VSR-AA features, but loaded up the same software version that was used for the performance tests.

      Instead of emulated traffic, we provided a real Internet connection to the VSR-AA and added a Radius server and client VM to the Supermicro server configuration. The Radius server was used to transfer Change of Authorization (CoA) messages to VSR-AA for in service app-profile modification.

      Figure 15: Figure 15: VSR-AA - Demo Setup Figure 15: VSR-AA — Demo Setup

      We configured a default subscriber profile matching a Linux client VM used for the test and allowed it to use Internet services without limitations.

      We validated the following features:

    • HTTP Redirection with URL Whitelisting for Captive Portal in WiFi/mobile networks: For this test, Nokia used the Radius server to apply subscriber profile changes on VSR-AA. Following a Radius policy-driven subscriber profile change, we could verify that a user browsing the Internet was properly redirected to the landing page configured in VSR-AA while still able to access Facebook and YouTube, which were included in the configured Whitelist. Figure 16: Figure 16: VSR-AA - URL Whitelisting Figure 16: VSR-AA — URL Whitelisting

    • URL Filtering/Blacklisting features: For this test, we verified that once a subscriber profile was modified using Radius CoA settings, specific web pages that are on the blacklist were not accessible. Instead, the user was redirected to a landing page used for this test case.

    • In-browser notification: This capability allows service providers to send subscriber notifications -- including quota information, late bill notice, location-based messages and welcome notifications -- via a user's web browser. Such notifications can be delivered over residential fixed line, cellular and WiFi connections. The example below displays a quota notification for a subscriber that has reached 100% of their usage allocation. Figure 17: Figure 17: VSR-AA - In Browser Notification Figure 17: VSR-AA — In Browser Notification

Read more about:

Europe
Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like