Multimedia Communication. Project 6: Intelligent DiffServ

Transcription

1 Multimedia Communication Project 6: Intelligent DiffServ Preliminary Design and interface definition ( ) Steffen Moser - 1 / 9 -

2 Necessary tasks of a DiffServ aware router: Classifying Marking Metering/Policing Queuing ( Queuing Discipline or qdisc ) Scheduling/Dropping As we want to implement DiffServ based on the operating system Linux, we do not have special-purpose routing hardware. How can the above given steps be done in a most efficient way anyhow? The tasks are handled by the Linux kernel itself. The kernel is also responsible for other networking matters (routing, firewalling, and so on). - 2 / 9 -

3 How do we tell the kernel what we want (e.g. DiffServ parameters, routing tables, firewalling rules)? The kernel offers an interface based on sockets which allows us to do our configuration in run-time ( NETLINK ). The features (e.g. marking and filtering capabilities) which we need from the kernel must be chosen when compiling the kernel. The following figure shows the interaction between kernel and user address space: - 3 / 9 -

4 Application can be any (e.g. self-written) application which communicates with the kernel and tells it our configuration. Usually the application tc (it stands for traffic control ) is used. It is a text based application shipped with the iproute2 package, so we do not have to deal with very low level things like NETLINK calls. steffen@pc01:~/iproute2/tc>./tc help Usage: tc [ OPTIONS ] OBJECT { COMMAND help } where OBJECT := { qdisc class filter } OPTIONS := { -s[tatistics] -d[etails] -r[aw] -b[atch] file } steffen@pc01:~/iproute2/tc>./tc qdisc help Usage: tc qdisc [ add del replace change get ] dev STRING [ handle QHANDLE ] [ root ingress parent CLASSID ] [ estimator INTERVAL TIME_CONSTANT ] [ [ QDISC_KIND ] [ help OPTIONS ] ] tc qdisc show [ dev STRING ] [ingress] Where: QDISC_KIND := { [p b]fifo tbf prio cbq red etc. } OPTIONS :=... try tc qdisc add <desired QDISC_KIND> help - 4 / 9 -

5 For setting up more complex traffic control rules (e.g. needed for a DiffServ compliant setup), shell scripts which invoke tc can make life easier: We can specify some global parameters at the head of the file which makes changes very easy. Shell scripts offer constructs like for, while, if. The kernel does not store the configuration permanently (on hard disk) but only within its address space. After shutdown we have got to set it up again - which is no problem if we have got scripts that contain the commands and parameters. - 5 / 9 -

6 Let's have a look at a simple shell script: #! /bin/bash TC=/usr/sbin/tc INDEV=eth0 RATE=6Mbit PRIO=100 # Set up FIFO qdisc (queue for 10 packets) $TC qdisc add dev $INDEV root handle 1: pfifo limit 10 # Add HTB (hierarchical token bucket) class to this queue $TC class add dev $INDEV parent 1:0 classid 1:1 htb rate $RATE prio $PRIO # Add U32 filter to class 1:1 $TC filter add dev $INDEV parent 1:0 protocol ip prio 1 u32 \ match ip dport 80 0xffff flowid 1:1 # Add U32 filter to another class (1:2) $TC filter add dev $INDEV parent 1:0 protocol ip prio 10 u32 \ match ip tos 0x10 0xff flowid 1:2-6 / 9 -

7 Traffic control is always based on qdiscs, classes and filters : An example for a simply aggregation would be: Recursive constructions ( qdiscs within qdiscs ) are allowed. - 7 / 9 -

8 As we have seen, using the U32 filter we can match characteristics of the packet's IP and TCP header (TOS, dport,...). To classify multimedia data (for example what kind of frame is sent within a packet) we have to look at a higher layer. Therefore U32 offers further (user defined) pattern matching functions: # Add U32 filter to class 1:1 which matches for IP dest addr $TC filter add dev $INDEV parent 1:0 protocol ip prio 1 u32 \ match u32 0xc0a xffffffff at 16 flowid 1:1 IPv4 header: Version IHL Type of Service Total Length Identification Flags Fragment Offset Time to Live Protocol Header Checksum Source Address Destination Address Options Padding - 8 / 9 -

9 User defined patterns may also be beyond (and before!) the IPv4 header within the IP payload data. Therefore we are able to match patterns within the payload of the packet. Of course, we need a well-defined transport protocol within UDP/IP, e.g. RTP. We also have to notice that the headers' length is variable. - 9 / 9 -