Moby Dick Consolidated System Integration Plan

D0103v1.doc Version 1 6.7.2003
Acknowledgment, Binding Request, and Home Address options), Routing option, Hop-by-hop option,
Authentication option, Encapsulating Security Payload (ESP) option, Fragment option, IPv6 (tunnelling),
and ICMPv6.
The goal of this software is simple: the filtering rules will not be directly written in the XXX. In fact, the
software offers the possibility to filter packets using a more or less complete subset of the different header
fields. Only the user, and/or the network administrator, thanks to their good knowledge of the network
protocols, is able to define precisely these rules. Thus, the code of the software is the same in all the
different entities of the network using it, and in all the different QoS domains. Only the contents of the
filters can change from an entity to another, or from a QoS domain to another.
4.1.2.9.5 DSCP Matching Table
When a user, or a network administrator, triggers a modification of the filters descriptions, the TUM
modifies the DMT automatically. In this section, we describe how this table is organized.
Filter number
(= line number)
0
1
2
3
4
…
N
Filter Pointer
Filter0Ptr
NULL
Filter2Ptr
Filter3Ptr
NULL
…
FilterNPtr
Table 3: 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.
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 26: Representation of a filter in the Linux kernel
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.
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
D0103v1.doc 41 / 168