Subject: [Diffserv] prototyping the diffserv mib

From: Remco van de Meent <[email-masked]>
Date: Wed, 29 Aug 2001 11:54:40 +0200

Hi,

During the past months I've been working on a prototype implementation
of the DiffServ MIB, running on Linux. I hereby send a short overview
of my work, outlining the kind of problems an implementor may expect in
this prototyping environment.

cheers,
Remco.

                          Prototyping the DiffServ MIB
                               on a Linux router

                                  August 2001
                               Remco van de Meent
                             <[email-masked]>

1. Introduction

This is an abstract of the result of the M.Sc assignment the author of this
report did at the University of Twente. The IETF diffserv WG[1] is working on
an SMIv2 MIB[2] for devices implementing the Differentiated Services
Architecture[3].

In this assignment, the 10th revision of the DiffServ MIB Internet Draft has
been prototyped. The prototyping environment is a router running the GNU/Linux
operating system, enhanced with DiffServ support from EPFL[4,5], running a
version 2.4 kernel. The full report as well as the C program code will be made
available from
http://www.simpleweb.org/nm/education/assignments/previous-assignments.html

The focus has been the monitoring part of management. Configurational aspects
have not been implemented, due to complexity and time constraints.

2. DiffServ Architecture and DiffServ MIB

The architecture defines a scalable and efficient way of service
differentiating on the Internet, by aggregating traffic classification state
information using the DSCP field in the IP-header.

The DiffServ architecture splits its functions up in various functional
elements, as outlined in the following figure:

                                +-------+
                                |       |-------------------+
                         +----->| Meter |                   |
                         |      |       |--+                |
                         |      +-------+  |                |
                         |                 V                V
                   +------------+      +--------+      +---------+
                   |            |      |        |      | Shaper/ |
     packets =====>| Classifier |=====>| Marker |=====>| Dropper |=====>
                   |            |      |        |      |         |
                   +------------+      +--------+      +---------+

The DiffServ MIB is closely modelled after this architecture. RowPointers are
used to ``hop'' fromone functional element to another. Parameterization of the
various functions is achieved by the use of ``specific'' tables. This gives a
flexible structure, where third parties can add their own tables with specific
information.

3. Linux Network Traffic Control Architecture

The Linux Network Traffic Control Architecture (TC) consists of three main
elements: queuing disciplines (qdisc), classes and filters. It is heavily
focused on the egress part of a router. Support for DiffServ has been built on
top of this generic framework.

Qdiscs determine how packets for certain interfaces or classes are treated,
like FIFO or RED. Various classes of traffic may be distinguished using
filters, which use IP header information (addressing, DSCP).  Filters are also
used to police (meter) traffic to make sure it matches a certain profile, with
a fall-trough mechanism for traffic that is not in profile. The concept of
Class Based Queueing (CBQ) is used to treat various classes of traffic (e.g.
``low'' and ``high'' priority) in different ways.

The picture below gives an example of a configuration that might be used to
implement the Expedited Forwarding per-hop behaviour. Class 1 matches traffic
with DSCP value 0x2e set, class 2 everything else.

          +--+   +--+               +-------+   +----+     +--+   +--+
          |  |   |  |   +------+ .->|class 1|-->|FIFO|-+   |  |   |  |
          |  |   |  |-->|filter|-'  +-------+   +----+ |   |  |   |  |
          |  |   |  |   +------+                       |   |  |   |  | 
 packets  |  |-->|  |      |        +-------+   +---+  `.  |  |-->|  |   
 ========>|  |   |  |      +------->|class 2|-->|RED|----->|  |   |  |====>
          |  |   |  |               +-------+   +---+      |  |   |  |
          |  |   |  +--------------------------------------+  |   |  |
          |  |   |    class based queueing                    |   |  |
          |  |   +--------------------------------------------+   |  |
          |  |                                                    |  |
          |  +----------------------------------------------------+  |
          |    sch_dsmark   queueing discipline                      |
          +----------------------------------------------------------+

In the TC, the DiffServ concepts of Queueing and Scheduling are taken care of
by the qdiscs and classes, Classification is done by filters and classes and
Metering is performed by filters. TC is not tailored for DiffServ, and these
mappings are non-trivial. The architectures are conceptually different.

Monitoring and configuration of TC in the kernel is done over ``netlink''
sockets, which is a special socket for exchanging routing and traffic control
information (among other things) between kernel and user-space processes.

4. DiffServ MIB and the Linux Kernel

As outlined in the previous paragraphs, both architectures are quite different
from each other. As the MIB closely follows the DiffServ Architecture,
problems arise when trying to monitor or configure DiffServ functionality in
the Linux kernel with this MIB.

For instance, the Counter element is used in the DiffServ Architecture for
counting packets that it receives at its input. Queueing disciplines however
keep some statistical information, including the number of dropped packets,
but it is not possible to attach a counter to a filter.

Not every table in the (current version of the) MIB can be filled with
sensible information, because of such constraints. Some of the flexibility the
MIB offers can't be used when managing DiffServ on a Linux router.

5. Conclusions and Recommendations

Routers that are not strictly modelled after the DiffServ Architecture may or
may not be fully managable using the DiffServ MIB. In the case of Linux using
the DiffServ implementation from EPFL it is not. Also there are better ways in
Linux to classifify and mark packets then using TC: the netfilter architecture
with its iptables command line utility. It might be possible to create a link
between a MIB implementation and netfilter, but netlink sockets cannot be used
as they are not supported by netfilter.

This doesn't mean that the MIB is not good: it seems well-equipped to manage
DiffServ functionality on routers implementing the DiffServ Architecture. The
use of RowPointers gives enormous flexibility.  So the author doesn't think
the MIB should be changed in this respect. Linux might not just be the easiest
platform to implement this MIB on.

Furthermore it doesn't necessarily mean that the management interface to TC
should be changed. It gives access to all the flexibility TC offers, and it
wouldn't be wise to drop part of that.  Management of TC using MIBs is
possible, but has not been implemented yet, as far as the author knows.
Interaction with the DiffServ MIB can certainly be achieved using RowPointers.

6. References

[1] IETF diffserv WG, Differentiated Services Working Group Charter Page
    http://www.ietf.org/html.charters/diffserv-charter.html

[2] Baker et al. Management Information Base for the Differentiated Services 
    Architecture. 
    http://www.ietf.org/internet-drafts/draft-iets-diffserv-mib-10.txt
    June 2001 (work in progress).

[3] Blake et al. Architecture for Differentiated Services (RFC 2475), 
    December 1998. 
    http://www.ietf.org/rfc/rfc2475.txt

[4] Differentiated Services on Linux, Homepage
    http://diffserv.sourceforge.net/

[5] Almesbergers et al. Differentiated Services on Linux.
    ftp://icaftp.epfl.ch/pub/linux/diffserv/misc/dsid-01.ps.gz, 
    June 1999

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html