Ralph Duncan

PacketC Language and Parallel Processing of Masked Databases

Network packet processing’s increasing speeds and volume create an incentive to use parallel processing. Such processing often involves comparing selected packet data to the contents of large tables (e.g., for routing packets or controlling system access). Thus, commercial systems often use multiple network processors [1] to provide parallel processing in general and use associative memory chips to provide parallel table operations in particular. Parallel network programming is usually done in a C dialect with machine-specific extensions. The associative memory capabilities are often provided by ternary content addressable memory (TCAM) chips in order to supply the fast, masking-based searches needed in this domain. TCAM use is normally controlled by vendor software, rather than by the application developer. Thus, an application is typically restricted to a small number of predefined templates and mediated by vendor system software. Thus, application developers cannot use high-level languages to express network table operations in an intuitive, portable way, nor exploit parallel devices like TCAMs in a flexible manner. This paper presents CloudShields packetC® language [2], a C dialect that hides most host-machine specifics, supports coarse-grain parallelism and supplies high-level data type and operator extensions for packet processing. We describe packetC’s database and record constructs that support network application table operations, including masked matching. We show how our implementation of packetC with network processors, FPGAs and TCAMs lets the user enjoy parallel performance benefits without the usual vendor constraints or reliance on hardware-specific programming.

A paradigm for processing network protocols in parallel

Network packet processing applications increasingly execute at speeds of 1-40 Gigabits per second, often running on multi-core chips that contain multithreaded network processing units (NPUs) and a general-purpose processor core. Such applications are typically programmed in a language that exposes NPU specifics needed to optimize low-level thread control and resource management. This facilitates optimization at the cost of increased software complexity and reduced portability. In contrast, our approach provides portability by combining coarse-grained, SPMD parallelism with programming in the packetC languages high-level constructs. This paper focuses on searching packet contents for packet protocol headers. We require the host system to locate protocol headers for layers 2, 3 and 4, and to encode their offsets data in a packet information block (PIB). packetC provides descriptors, C-style structures superimposed on the packet array at runtime-calculable, user or PIB-supplied offsets. We deliver state-of-the-practice performance via an FPGA for locating layer offsets and via micro-coded interpretation that treats PIB layer offsets as a special addressing mode.

Packet Content Matching with packetC Searchsets

Increasing speeds and volumes push network packet applications to use parallel processing to boost performance. Examining the packet payload (message content) is a key aspect of packet processing. Applications search payloads to find strings that match a pattern described by regular expressions (regex). Searching for multiple strings that may start anywhere in the payload is a major obstacle to performance. Commercial systems often employ multiple network processors to provide parallel processing in general and use regex software engines or special regex processors to speed up searching performance via parallelism. Typically, regex rules are prepared separately from the application program and compiled into a binary image to be read by a regex processor or software engine. Our approach integrates specifying search rules with specifying network application code written in packet C, a C dialect that hides host-machine specifics, supports coarse-grain parallelism and supplies high-level data type and operator extensions for packet processing. packetC provides a search set data type, as well as match and find operations, to support payload searching. We show that our search set operator implementation, using associative memory and regex processors, lets users enjoy the performance benefits of parallel regex technology without learning hardware-specifics or using a separate regex toolchain’s use.

FPGA-Driven Table System to Accelerate Network Flows

Commercial products using hardware and firmware for high-speed network flow tracking are commonplace but typically restrict users to a few predefined options. Conversely, ensemble architectures with multiple network processing units (NPUs) and specialized accelerators are flexible enough for many tasks but relatively slow at routine flow management tasks. The paper presents a system that combines a field programmable gate array (FPGA)-driven table system with an ensemble network architecture. The system is especially effective when the FPGA system tracks flows and sends only selected packets to NPUs for further processing. The principal design goal is to achieve FPGA-level speed when processing tables for flows, actions, packet modification, key search and hash extraction and yet to allow users to initialize and dynamically modify the tables in terms of flexible, high-level packetC language types and structures.

Managing Heterogeneous Processor Machine Dependencies in Computer Network Applications

Executing complex network packet applications typically requires using network processors and parallel processing to handle packet transmission speeds of 1 gigabit per second and beyond. Heterogeneous computing approaches also employ specialized coprocessors, such as associative memory processors for flow matching and regular expression (regex) processors for packet payload searching. Our goals for this kind of heterogeneous processing are to free application developers from hardware-specific details and to develop systems in which we can deploy new hardware and software components in modular, plug-and-play fashion. Our initial contribution to realizing these goals involves (1) expressing classic packet operations in a C dialect as C/C++-style operators; (2) compiling user code into bytecodes for a packet-processing virtual machine that hides machine-specific details; and (3) interpreting the bytecodes with microcoded interpreters that orchestrate an ensemble of heterogeneous processors on the users’ behalf.

Reference Variables for Dynamic, Reliable Packet Operations

A classic ‘reference’ variable provides an indirect way to access a variable or aggregate. packetC, [1] a language for network packet processing, has specialized requirements for references that apply to aggregates, based on domain-specific, extended data types. The primary functional requirement is to defer selecting particular aggregates until runtime. In addition, requirements for high program reliability and security are paramount. Thus, packetC reference constructs must guarantee that a selected aggregate (i.e., the value of a runtime dereference) always constitutes a legal aggregate for the involved operation. Both reliability concerns and current domain implementation practice discourage references based on addresses (detailed below). A secondary requirement is to support chaining aggregate operations, where the aggregate used in an operation depends on the result of the previous operation. Our design and implementation of packetC references provides a useful case study in how secure, reliable references can meet these requirements by combining strong typing features (e.g., declaration rules), simple mechanics (encoded ordinal values) and appropriate technical attributes for references, such as reseatability and non-nullability.

Dynamically Accessing Packet Header Fields at High-Speed

A significant part of packet processing consists of detecting whether certain standard protocol headers are present, where they are located and whether they include optional information. Packet processing programs are on tight time budgets, especially to handle speeds in the gigabits per second (gbps) range. Thus, high-speed mechanisms for finding and accessing headers are critical. Our approach lets users define headers as C-style structures in a high-level language, packetC [1], and specify header locations in terms of offsets from the start of the current packet, which is treated as an array of unsigned bytes. These offsets can be expressed in terms of network layer offsets, constant values, runtime-calculated variables and combinations of all of these. This paper focuses on the principal forms these offset expressions can take and on how our FPGAs (Field Programmable Gate Arrays), compiler and interpreter collectively handle them at runtime. For simple and complex header offset scenarios we provide users with intuitive, high-level ways to describe offsets and provide effective runtime mechanisms to access header fields.

Descriptor Type and Operations

packetC provides data types that do not appear in standard C but do provide significant support for packet-processing applications. These data types are often extensions of familiar C types. The extended data type described in this chapter is descriptors. This chapter is divided into two different approaches. The first part of this chapter is focused on simply covering examples of descriptors and the packetC standard include file protocols.ph. The second part of this chapter covers an in-depth view into the background of the descriptors and how they operate under the hood as these are new to packetC.

Construction of a packetC Program

packetC is designed to be used with parallel-processing runtime environments, although an implementation may be compliant without providing this. The language was designed for environments in which a packetC program will typically be executing with large numbers of simultaneous contexts. In packetC, similar to interrupt service routines, the arrival of a packet is an event that triggers processing by a context. The packetC program is considered re-entrant and is designed such that more than one copy is executing at any point in time. Parallel processing is based upon each context running the entire application from receipt of a packet to completion of processing for the assigned packet. The packetC language specification does not prescribe how actual or apparent parallelism must be implemented. Hence, each copy of a packet module or shared module is termed a context, since the terms process, task, or thread imply how parallel execution is to be implemented and imply characteristics that may vary from one operating system to another.

C-Style Data Types

Working with data types in packetC introduces some interesting dynamics that will initially require care and extra thought by C developers from time to time given some of the restrictions, mostly due to strong type enforcement. The notion of casting and the strong casting rules is imperative to ensuring code works as expected. Packets are modeled as arrays of bytes and working with portions of packets is essential to making sense of the data. In packetC, the notion of an array slice was introduced to allow for direct access to portions of byte arrays without the need for pointers and for keeping them in line with strong type enforcement. This also applies to complex structures and unions that can be copied or, better yet, cast back and forth to byte arrays, providing multiple ways to view data elements, depending on what is most convenient for the programmer.