Moby Dick Consolidated System Integration Plan

D0103v1.doc Version 1 6.7.2003
Filter number
(= line number)
0
1
2
3
4
…
N
Filter Pointer
Filter0Ptr
NULL
Filter2Ptr
Filter3Ptr
NULL
…
FilterNPtr
Table 12: Format of the DMT
Each line of the table only contains a pointer to a complete description of a filter loaded in the memory
(see Table 3).
Each filter is a simple structure containing a description, the DSCP (CoS) used to mark each packet that
matches this filter, a set of bits identifying the different headers to examine, and a pointer to a list of items
representing the different fields of the packet header that are to be inspected (see figure 26). Thus, the
number of fields in a filter is variable. The bits identifying the different headers to examine accelerate the
filtering process. Indeed, if a filter contains items related to TCP fields, and if the packet does not contain
a TCP header, the filter doesn’t match, and browsing its items list and the header fields’ values becomes
useless. The use of these bits avoids useless treatments in the DMF.
Every item of this list contains an identification of the field to inspect, i.e. a value identifying the name of
the field in the kernel (IP6_SRC_ADDR is equivalent to the IP6SrcAddr field in the FD,
TCP_SRC_PORT is equivalent to the TCPSrcPort field, etc.), the expected value of this field, and a
pointer to the next item.
It is possible that the information extracted from the packet header matches with several filters. Only the
first filter is taken into account. Thus, the number of the filter, which is the range of the filter in the table,
represents its priority. The lower is this number, the greater is the priority of the filter. So, it is important
to sort the filters from the more detailed to the less detailed.
Desc.: ANiceFilter
Headers:IP6, TCP
CoS: 101101
Items list: item1
Ident.: IP6_SRC_ADDR
Value: FEC0::1
Next: item2
Ident.: IP6_DSCP
Value: 010110
Next: item3
Ident.: TCP_SRC_PORT
Value: 21
Next: NULL
Figure 50: Representation of a filter in the Linux kernel
Table updates
The TUM modifies the DMT each time the user, or the network administrator, modifies the FD and
communicates it to the module (figure 27). The modified FD – which is a single text file – is forwarded to
the module over a simple Linux character device (/dev/dscp). This solution is the simplest way to
communicate information from the user space (here, the FD) to the kernel space where the DMT is
located.
Thus, the user only has to write on this device with the contents of the FD (by the ‘cat filters_database.txt
> /dev/dscp’ command for ex.). Then, the TUM automatically reads the text written on the device, and
updates the DMT in the Linux kernel. Note that it is not necessary to write the entire FD on the device to
update properly the DMT: only a file containing new filters, or a subset of modified filters can be
communicated to the TUM.
D0103v1.doc 63 / 168