FPL

The FPL language is summarised in Figure 5. It supports all common integer types (signed and unsigned bits, nibbles, octets, words and double words) and allows expressions to get hold of any field in the packet header or payload in a friendly manner. Moreover, offsets in packets can be variable, i.e., determined by an expression. For convenience, an extensible set of macros allows use of shorthand for packet fields, e.g., instead of asking for bytes nine and ten to obtain the IP header's protocol field, a user may abbreviate to `IP_PROTO'. We briefly explain constructs that are not intuitively clear.

Figure 5: FPL-2 language constructs ($^\dagger$ m and $n$ arbitrary variables)

FOR.

The FOR loop construct is limited to loops with a pre-determined number of iterations. The break instruction, allows one to exit the loop `early'. In this case (and also when the loop finishes), execution continues at the instruction following the ROF construct.

Registers and memory.

FPL is able to access the filter's by means of the assignment operator. For instance, one may assign the content of a memory location to a register, perform a set of calculations, and then assign the value of the register back to memory. All accesses to are checked for bounds violations. An example of usage in FPL-2 is shown in Figure 6. The code implements the filter $f$ mentioned in Section 3.1.2 that keeps track of how many packets were received on each TCP connection (assuming for simplicity that the hash is unique for each live TCP flow).

Figure 6: Example of FPL-2 code: count TCP flow activity

External functions.

An important feature of FPL is extensibility and the concept of an `external function' is key to extensibility, flexibility and speed. External functions are an explicit mechanism to introduce extended functionality to FFPF and add to flexibility by implementing the `filter call' semantics shown in Figure (2.b). While they look like filters, the functions may implement anything that is considered useful (e.g., checksum calculation, pattern matching). They can be written in any of the supported languages, but it is anticipated that they will often be used to call optimised native code performing computationally expensive operations.

In FPL, an external function is called using the EXTERN construct, where the parameters indicate the filter to call, the offset in where the filter can find its input data (if any), and the offset at which it should write its output, respectively. For instance, EXTERN(foo,x,y) will call external function foo, which will read its input from memory at offset $x$, and produce output, if any, at offset $y$. Note that FFPF does not prevent users from supplying bogus arguments. Protection comes from authorisation control discussed in Section 3.4 and from the compiler. The compiler checks the use of external functions in a filter. An external function's definition prescribes the size of the parameters, so whenever a user's filter tries to let the external function read its input from an offset that would make it stray beyond the bounds of the memory array, an error is generated. This is one of the advantages of having a 'trusted' compiler (see also Section 3.3.3. In addition, authorisation control can be used to grant users access only to a set of registered functions.

A small library of external filter functions has been implemented (including implementation of popular pattern matching algorithms, such as Aho-Corasick and Boyer-Moore). The implementation will be evaluated in Section 5. External functions in FPL can also be used to `script together' filters from different approaches (e.g., BPF+ [5], DPF [17], PathFinder [3], etc.), much like a shell script in UNIX.