Moby Dick Consolidated System Integration Plan
Share Embed Flag
Download ePaper

Moby Dick Consolidated System Integration Plan

Moby Dick Consolidated System Integration Plan Moby Dick Consolidated System Integration Plan

kt.agh.edu.pl
from kt.agh.edu.pl More from this publisher
27.03.2014 Views

D0103v1.doc Version 1 6.7.2003 • a Filters Database (FD): this file (or set of files) contains the definitions of all the filters, in the user space, • a Table Update Module (TUM): this is a Linux module in charge of updating the DSCP Matching Table with the data stored in the Filters Database, • a Service Table (ST): this table, only used by the TUM, associates a DSCP with each service. 4.1.2.9.3 DSCP Matching The packet marking process is based on the search of a table containing all the filters definitions whenever a packet is ready to be transmitted. In this section, we describe how these filters are introduced by a user, and how the DMT is built and updated. Kernel Space User Space DSCP Marking Function (IPv6) Table update Module Service Table DSCP Matching Table Filters Db Rules1.txt Rules2.txt Rules3.txt Figure 25: DMS Components 4.1.2.9.4 Packet filtering The description of a filter is as follows: Filter Description TCPDestPort IP6SrcAddr CoS 10 FTPFilter 21 FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 S1 Table 2: Filter Description The complete descriptions of the filters are stored in one or several files (the FD). Each file is loaded in the DMT with help of the TUM. Then, when a packet is ready to be delivered to the lower layer, the DMF consults the DMT, and marks the packet with the DSCP associated with the first filter that matches with the information of its header(s). A filter contains: • An identifier (the ‘Description’ field), which also represents its priority. Thus, if two filters match, only the first one, i.e. the one with the lowest identifier, is considered. • A description, i.e. a filter name. • A CoS: the value of this field can be either a service identifier (S1, S2, …) or a DSCP. If this value is a service identifier, then the DSCP associated with the filter will be found by the TUM in the ST. • A list of items, with their values. The number of items is not limited, and a list of items can be empty (then, all the packets are marked with the DSCP associated with the filter). Packets are marked with the DSCP associated with the filter only if all the items values are equal to the corresponding fields values in the different headers of the packet. On the previous example, a packet will be marked with the ‘101110’ DSCP (which is associated with the S1 service in the ST) only if, in the packet headers, the TCP Destination Port is set to ‘21’ and the IPv6 Source Address is set to ‘FEDC:…:3210’. If only one value doesn’t match, then the filter also doesn’t match. Typically, each description can use all the possible fields of the different headers added by the network and the transport layers. This software supports a large subset of these fields, in the following headers: IPv6 main header, TCP, UDP, Destination option (including the Binding Update, Binding D0103v1.doc 40 / 168

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

D0103v1.doc Version 1 6.7.2003<br />

• a Filters Database (FD): this file (or set of files) contains the definitions of all the filters, in the user<br />

space,<br />

• a Table Update Module (TUM): this is a Linux module in charge of updating the DSCP Matching<br />

Table with the data stored in the Filters Database,<br />

• a Service Table (ST): this table, only used by the TUM, associates a DSCP with each service.<br />

4.1.2.9.3 DSCP Matching<br />

The packet marking process is based on the search of a table containing all the filters definitions<br />

whenever a packet is ready to be transmitted. In this section, we describe how these filters are introduced<br />

by a user, and how the DMT is built and updated.<br />

Kernel Space<br />

User Space<br />

DSCP Marking<br />

Function (IPv6)<br />

Table update<br />

Module<br />

Service<br />

Table<br />

DSCP<br />

Matching<br />

Table<br />

Filters<br />

Db<br />

Rules1.txt<br />

Rules2.txt<br />

Rules3.txt<br />

Figure 25: DMS Components<br />

4.1.2.9.4 Packet filtering<br />

The description of a filter is as follows:<br />

Filter<br />

Description<br />

TCPDestPort<br />

IP6SrcAddr<br />

CoS<br />

10<br />

FTPFilter<br />

21<br />

FEDC:BA98:7654:3210:FEDC:BA98:7654:3210<br />

S1<br />

Table 2: Filter Description<br />

The complete descriptions of the filters are stored in one or several files (the FD). Each file is loaded in<br />

the DMT with help of the TUM. Then, when a packet is ready to be delivered to the lower layer, the DMF<br />

consults the DMT, and marks the packet with the DSCP associated with the first filter that matches with<br />

the information of its header(s).<br />

A filter contains:<br />

• An identifier (the ‘Description’ field), which also represents its priority. Thus, if two filters<br />

match, only the first one, i.e. the one with the lowest identifier, is considered.<br />

• A description, i.e. a filter name.<br />

• A CoS: the value of this field can be either a service identifier (S1, S2, …) or a DSCP. If this<br />

value is a service identifier, then the DSCP associated with the filter will be found by the TUM<br />

in the ST.<br />

• A list of items, with their values. The number of items is not limited, and a list of items can be<br />

empty (then, all the packets are marked with the DSCP associated with the filter). Packets are<br />

marked with the DSCP associated with the filter only if all the items values are equal to the<br />

corresponding fields values in the different headers of the packet. On the previous example, a<br />

packet will be marked with the ‘101110’ DSCP (which is associated with the S1 service in the<br />

ST) only if, in the packet headers, the TCP Destination Port is set to ‘21’ and the IPv6 Source<br />

Address is set to ‘FEDC:…:3210’. If only one value doesn’t match, then the filter also doesn’t<br />

match.<br />

Typically, each description can use all the possible fields of the different headers added by the network<br />

and the transport layers. This software supports a large subset of these fields, in the following headers:<br />

IPv6 main header, TCP, UDP, Destination option (including the Binding Update, Binding<br />

D0103v1.doc 40 / 168

logo

products

Resources

Company

Terms of service
Privacy policy
Cookie policy
Cookie settings
Imprint
Change language
Made with love in Switzerland
© 2024 Yumpu.com all rights reserved

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!