Moby Dick Consolidated System Integration Plan

D0103v1.doc Version 1 6.7.2003
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.
User
AAAC
Table update
Module
3b
Filtering Rules & DSCP
1 2 3a
Service
Table
Character device
/dev/ dscp
1: Filters writing
2: Filters reading
DSCP
Matching
Table
3a: DSCP update
3b: Filters update
Figure 27: DMT and SC update process
For the moment, the table update process is triggered manually, by writing on the /dev/dscp character
device. However, it is possible to make the AAAC system update the FD, in the same way than the DSCP
update (see section 4.1.2.9.8) or triggering automatic updates regularly, in the user space.
4.1.2.9.6 DSCP marking
DSCP marking is done thanks to a modification of the Traffic Class and Flow Label fields in the IPv6
header. When the information of the packet header matches with a filter, the corresponding DSCP is
marked in the header of the packet: the four first bits of the DSCP are stored in the last four bits of the
Traffic Class field, and the last two bits, plus two bits set to ‘0’, are stored in the four first bits of the Flow
Label field.
DSCP
Vers
TC
…..
Flow Label
Figure 28: DSCP bits in the IPv6 main header
4.1.2.9.7 Packet re-marking
This operation is supported by the DMT, if the DMS is installed in a Linux router. To re-mark packets,
the network administrator has just to add a new filter, containing a ‘IP6DSCP’ item, in the FD. This filter
evaluates the DSCP in the new packet header, and associates a new value with it.
4.1.2.9.8 DSCP updates and interaction with AAAC
In the first version of the DMS, provided in October 2002, the ‘CoS’ field value in each filter in the FD
was only a DSCP (e.g. ‘110110’, …). However, if we consider that several users can be located on the
same MT, but with different QoS contracts, the same applications may use different QoS services for two
different users. Thus, when a user enters in a new domain, she has to load the proper DSCP for each
service she’s authorized to ask for, and to associate each service to each application she can launch. The
second version of the DMS, provided in March 2003, offers the possibility to the user to use both DSCP
values and service identifiers in her filters. In fact, a user can write a service identifier in the ‘CoS’ field
D0103v1.doc 42 / 168