18-06-2013, 11:03 AM
Traffic control in linux kernel
Traffic control.pdf (Size: 145.15 KB / Downloads: 34)
Abstract
The aim of Traffic control in linux kernel includes Diffserv implementation for the
Linux kernel.It is necessary to map the various management functions offered by the
MIB to functions provided by the DiffServ implementation.This leads to the conclusion
that conversion needs to be done before the MIB can be filled with values from the
kernel (like counters), and that conguration information that is written into the MIB
by a manager application need to be translated to the correct rtnetlink messages.
Introduction
The tipic is an overview of the architecture of the Network Traffic Control code and
describes its structure, as well as the DiffServ specific parts. It is necessary to look into
this as the structure of the DiffServ MIB is different from the DiffServ implementation
in Linux. This conflict leads to problems that need to be solved in order to implement
the DiffServ MIB.
The DiffServ MIB and the Linux Kernel
A DiffServ implementation for the Linux kernel doesn’t know about the
DiffServ MIB specification. Therefore, it is necessary to map the various management
functions offered by the MIB to functions provided by the DiffServ implementation.
The management of both designs is tailored after the respective architectures: the
MIB is modeled after the DiffServ Architecture, but the kernel is to be configured
using handles that are pointers to the various elements by sending rtnetlink messages.
This leads to the conclusion that conversion needs to be done before the MIB can
be filled with values from the kernel (like counters), and that conguration information
that is written into the MIB by a manager application need to be translated to the
correct rtnetlink messages. It is clear that various protocols have to be combined .
OVERVIEW OF TRAFFIC CONTROL
TC can, among other things, decide whether a packet should be queued
or dropped (the latter for example in case where the traffic exceeds certain thresholds),
in which order packets are sent (hence giving priority to certain network traffic flows)
and it can delay the sending of packets (e.g. to limit the rate of outbound traffic).
Once TC has released a packet for sending, the device driver picks it up and emits
the packet to the network. The TC framework consists of four major conceptual components that are discusses in the following subsections:
• queueing disciplines
• classes
• filters
• policing
Classes
Every queueing discpline has one ore more classes attached to it. The
very existence of classes, and their semantics, are fundamental properties of a queueing
discpline (qdisc). A qdisc uses classes to treat various classes of traffic in different ways.
Note that this distinction is made using filters. Classes are not storage places, they
can use other queueing disciplines for that. So within a queuing discipline attached
to a network device, other queuing disciplines may reside. And to these qdisc’s, other
filters and classes may be attached, hence giving enormous flexibility (and complexity
in configuration) to the user of the TC framework.
The DiffServ MIB and the Linux Kernel
Representing information from the kernel
The prototyping in this assignment is focused on the monitoring part of
the manager-agent paradigm, i.e. the manager retrieves some values from the agent.
Therefore the implementation of the agent needs to gather information when it is
requested to do so (or on its own). In the case of the DiffServ MIB agent, this means
that the agent has to get information from the kernel using the rtnetlink messages.
This sections covers the various tables from the DiffServ MIB and explains what needs
to be done in order to retrieve the requested information.
Data Path Table
This tables merely is a starting point for the DiffServ management in-
formation. The network interfaces are numbered according to the if Table numbering,
which happens to be the same as the internal numbering used in the Linux kernel.
This information is retrieved using a RTM-GETLINK message. No conversion needs
to be done at all, though parsing of the resulting message remains necessary of course.
Classifier tables
In the MIB there is the SixTuple Classifier which makes it possible
to represent any part of the IP and transport layer headers in the MIB, like IP
addresses, DSCPs and port numbers. The Classifier tables are indexed by two separate
identifiers, enumerating the classifier entries and the classifier element entries. In
Linux, there is no unique identification for a filter. Elements within a single filter
are identified with a handle though. Multiple filters belonging to the same queueing
discipline or class are ordered by a numerical priority value. Thus a DiffServ MIB
implementation must take care of assigning unique identifiers to the filters and their
elements itself.