Dwight Mulcahy

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.

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.

packetC Data Type Fundamentals

When it comes to working with data types and changing some rules from C99, packetC has done its best to treat types consistently and yet advance language practice by refining how packet data is defined and manipulated. As packet processing is all about analyzing byte streams of packet data into protocol and payload information, appropriate, domain-specific data types are central to packetC. Informally, complex data types are those other than the basic scalar types such as byte, short, int, and long. packetC complex types include traditional C types such as enumerations, arrays, structures, unions, and our extended types such as databases, records, searchsets, descriptors, and references, which are built on familiar type principles and practices.

Packet Information Block and System Packet Operations

Unlike C, packetC is based upon the presumption of underlying capabilities being provided by the operating system or generated by the compiler for a target platform. These include the management of packet handling functionality including receipt, buffering, and transmission as well as an initial level of decoding and manipulation on transmission. In addition, parallel processing management and a base set of control plane functionality must be present for packetC applications to interact with. These functions may differ from one system to another; however, a base set of functionality must remain consistent. To provide a common interface, the language specification for packetC mandates a predefined base set of types that are passed as parameters to main() as well as a set of built-in methods and operators.

packetC Standard Networking Descriptors

This chapter highlights some of the key principles of descriptors through highlighting examples in the standard libraries. Many layer 2 through 4 descriptors are provided with packetC development environments while upper-layer protocols and custom packet techniques will require handcrafted descriptors tailored to an application. Descriptors may be as simple as the one for Ethernet II provided below: Open image in new window

Style Guidelines for packetC Program

This chapter covers packetC coding-style recommendations based on common C++ development community practices. The following recommendations establish the guidelines that CloudShield-developed software is expected to follow within packetC. As always with style guidelines, these are suggestions and individual third-party developers may choose to follow their own style guidelines and packetC compilers shall not be your jury.

Introduction to the packetC Language

The primary objective in the packetC design is to define a language that will allow software developers to use familiar, high-level language constructs to express coding solutions for packet processing applications for general purpose, and for CloudShield-enabled platforms in particular.

Basic Packet Interaction and Operations

The packet can be seen as either one of the simplest data elements in the language or one of the most complex, and hopefully both in a good way. In its simplest form, the packet is an array of bytes, as defined in cloudshield.ph, it simply looks similar to the statement below: Open image in new window