Over the last few years, service providers have introduced a wide array of differentiated services to tap new revenue sources and meet growing business and consumer demand for network usage. These service classes, ranging from VoIP to VPNs, often require that service providers meet even more stringent performance requirements than in the past. To support these new applications, service providers have increasingly turned to Service Level Agreements (SLAs) to define the contractual relationship between the parties, and specify the classes of traffic to be provided, the amount of data to be sent for each class, and the level of network performance to be guaranteed.
This trend has a major impact on network equipment design. To support a growing portfolio of service classes and verify agreements, service providers must now count packets and maintain an expanding amount of statistics on network performance and usage. The statistics commonly tracked in IP networks such as those kept for TCP, UDP, ICMP, IPSec, IPv4, IPv6 and Ethernet interfaces of any networked PC or Apple computer may readily be displayed by typing "netstat –s" at a command prompt. Although the PC system resources used to perform this type of statistics gathering are negligible, the overhead for the network equipment that aggregates a large number of users is very different (See Table 1). With line rates rising from OC-48 (2.5 Gbps) to 10 Gbps aggregated rates and OC-192, oversubscription techniques and network usage is climbing, and the size of the task has begun to overwhelm the capabilities of core packet processors.
Table 1. Simplified statistics-gathering scenario
In addition to the number of counters required to satisfy the need for the number of flows and flow parameters counted, it is important to consider the effect of both aggregate data rate and the traffic type on counter update rates. Using the same scenario, the counter update rate may be calculated (See Figure 1).
Click here for Figure 1
Given the rapid migration to 10G data rates, coupled with the transition from simple file downloads to session-based traffic, network equipment developers require a new approach to performing statistical operations. Over the long term, the size and scope of the statistics function limits the ability of a line card's core packet processor to process packets and maintain network line rates. The challenge for equipment designers is to find a new and more efficient way to track the growing volume of data without compromising packet-driven operations. By offloading this essential task from the primary packet processor, network equipment designers can free up the processor cycles needed to perform deeper packet classification and support the higher levels of encapsulation and longer search keys next-generation network applications require.
Traditionally, network equipment designers opted to perform statistics operations in software. This task was usually managed by a general purpose CPU or NPU core packet processor, and supported by external SRAM.
As long as data rates remained relatively low, the approach performed well. However, as network line rates rise, the limitations of traditional load/store architectures are increasingly apparent. In this topology, the core packet processor must fetch data from off-chip memory, perform such appropriate arithmetic operations as an increment, decrement or add a counter, and then write data back to external memory. This convoluted process expends packet processor cycles and is bandwidth intensive across the memory bus between the CPU and external memory. As line rates rise, the number of statistics operations and usage of the memory bus may starve the processor cores of context or data, causing the processor to stall and line-card performance to suffer.
Network equipment designers attempted to address the problem by offloading all or parts of the statistics task from the core packet processor. Some designers moved the statistics function to dedicated logic in an FPGA, for example, or integrated it into an ASIC. Both of these solutions present major liabilities, however. FPGAs do not offer the on-chip memory densities that high-speed statistics operations require at today's line rates. Accordingly, designers must support the FPGA with an external SRAM and face the same read/modify/write latencies associated with traditional addressing and SRAM configurations. Dedicated ASICs offer higher performance and the ability to add larger quantities of memory on-chip. But with average ASIC NREs exceeding a million dollars, the task of designing, verifying and validating an ASIC dedicated to statistics calculations remains prohibitively expensive.
The questions facing network equipment designers become: how can the problem be solved in a cost-effective manner , how can the core packet processor, whether an NPU, ASIC or FPGA, be freed up and allowed to focus on the packet classification functions it was originally designed to address? Ideally, the solution is comprised of a low-cost, off-the-shelf co-processor optimized for this specific function and designed to eliminate the stalling issues outlined above. A solution is also required that offers a high-performance, industry-standard interface that will simplify line-card design and support the growing array of NPUs and dedicated packet processors currently in use. Finally, any solution should be highly software configurable to support widely divergent application needs.
Session border controllers
One way to illustrate how a statistics engine can help address the offloading of statistics operations is to examine how it can be implemented in a session border controller (SBC). Riding the rising tide of VoIP deployment, SBCs play a key role in these networks by controlling real-time session traffic at the signaling, call-control and packet layers, as data crosses the border between networks or network segments. These devices typically sit between a trusted private network, such as a private corporate LAN, and an untrusted public network such as the Internet, or between two service provider networks. They provide access to VoIP signaling messages to the core of the network and, by controlling access of media packets to the network, support differentiated services such as billing and QoS for different media streams. Designed to secure the borders of a network, SBCs play a crucial role in the traversing of firewalls between networks and help apply such regulatory mandates as lawful interception of packetized voice.