Traditionally Network Packet Brokers have been built on purpose-built hardware implemented using FPGA or ASIC. These hardware-based packet brokers are excellent in processing packets at line rate, in a deterministic way, that is, they keep the latency variation between packets from ingress to egress to a predictable minimum. Incumbent vendors have implemented a whole bunch of packet modification uses cases in hardware, such as timestamping, port stamping, de-duplications and so on. Highly resource intensive functions, such as correlation of GTP-C and GTP-U protocol packets too get implemented on FPGA.
Trade off - Performance vs. Flexibility
From a customer’s perspective, it is not always about best performance. They want a feature-rich and flexible packet broker system to optimize the use of their probing and analytics platforms. Some of the interesting use cases are correlation of SGi with RADIUS/Diameter in order to reuse their DPI boxes or to try out the new open source IDS system. Another example could be when a new handset is being launched, the operator wants to monitor the traffic from specific UE (User Equipment) till it is proven in their network. What if the customer wants to monitor traffic originating from a specific eNodeB or a set of eNodeBs or newly launched service? Bottom line – Networks evolve and so do use cases. Monitoring needs change all the time, and that results in complex filtering and protocol correlation at the packet broker-level. Adding new features into FPGA /ASIC-based packet broker could be tricky.
The crux of the problem is incumbent vendors trying to implement a complex algorithm such as correlation or APN-based redirection in FPGA while the algorithm is best implemented in software. Adding a new feature in FPGA is not easy. Try asking a FPGA developer. The developer will be worried about the gate count, free resources available, timing impact on existing state machines when you add a new function to it and so on. Even if the FPGA had lot of free resources, turn-around time for adding new features is always high compared to that of software. These things make FPGA-based systems expensive and inflexible.
How about if the packet broker was intelligent enough to cross-correlate various user plane and control plane traffic protocols, and filter traffic based on any 3GPP parameter, and finally provide the exact subset of traffic the customer is looking for. It is a lot cheaper to analyze a smaller subset of traffic. However, thanks to fully FPGA-based architecture and its inherent lack of flexibility, the customer is forced to invest in an expensive Probe layer and analytics solution to pick up the traffic/KPI of interest.
Take a look at x86-based architecture. All three dimensions - I/O bandwidth, Processing Cores per CPU and Memory capacity - have been soaring, while price per performance is falling. For example, Single Off-the-shelf PCIe x8 NIC Card can push 60 Gbps of traffic in and out of a server with a few CPU cores worth of processing power. CPU cores are growing, topping 18 Core per CPU socket. Servers typically come with two such CPUs, and combined with Hyperthreading there are 72 CPU cores available to process packets. Until a few years back, this kind of hardware was firmly in the NPU realm. However, it is not uncommon to see 256GB or 512GB of RAM these days. Software frameworks such as Intel DPDK enables the programmer to use all these hardware resources in an effective and meaningful way.
It is not unimaginable to push and process 200+ Gbps of traffic through COTS hardware such as Dell or HP for $15k.
There are few functions that are commonsensical and cheaper to implement in hardware such as timestamping and Packet replication. While higher-level feature sets are best implemented in software.
Hardware - Software Hybrid
What am I saying? There are two dimensions to the problem a typical packet broker solves in operator network, performance and functionality. FPGA-based packet brokers maximize on just one dimension. Brocade Packet Broker, with its hybrid architecture, attempts to maximize both the dimensions.
Brocade Packet Broker takes advantage of its own FPGA-based hardware architecture and combines it with Brocade Session Director, which is a fully performance-optimized software for x86 server architecture. This architectural choice results in a highly flexible packet broker with interesting use cases such as any-protocol-to-any-protocol correlation, filtering and re-direction use cases that cannot be accomplished by any FPGA/ASIC-based system and so on. Adding new features is quicker and cheaper with this architecture. And the best part, the customer gets to ride on the Moore’s law.