inetdoc.net

Avant tout, il serait préférable de lire les RFC écrits sur ce sujet (RFC2474, RFC2475, RFC2597 et RFC2598) sur le site web du groupe de travail DiffServ IETF et sur le site web de Werner Almesberger (Il a écrit le code permettant le support des Services Différenciés sous Linux).

DSMARK est un gestionnaire de mise en file d'attente qui offre les fonctionnalités dont ont besoin les services différenciés (Differentiated Services) (également appelés DiffServ ou tout simplement DS). DiffServ est l'une des deux architectures actuelles de la Qualité de Services (QoS : Quality of Services) (l'autre est appelée services intégrés (Integrated Services). Elle se base sur la valeur du champ DS contenu dans l'en-tête IP du paquet.

Une des premières solutions dans IP pour offrir des niveaux de qualité de services était le champ Type de Service (octet TOS) de l'en-tête IP. En modifiant la valeur de ce champ, nous pouvions choisir un niveau élevé/faible du débit, du délai ou de la fiabilité. Cependant, cela ne fournissait pas une flexibilité suffisante pour les besoins de nouveaux services (comme les applications temps réel, les applications interactives et autres). Par la suite, de nouvelles architectures sont apparues. L'une d'elle a été DiffServ qui a gardé les bits TOS et les a renommés champ DS.

Les services différenciés sont orientés groupes. Cela signifie que nous ne savons rien des flux (ce sera le but des services intégrés (integrated Services)). Nous connaissons en revanche les agrégations de flux et nous adopterons des comportements différents suivant l'agrégation à laquelle appartient le paquet.

Quand un paquet arrive à un nœud frontalier (nœud d'entrée du domaine DiffServ) et entre dans un domaine DiffServ, nous devrons avoir une politique, une mise en forme et/ou un marquage de ces paquets (le marquage fait référence à la mise en place d'une valeur dans le champ DS. Comme on le ferait pour des vaches :-)). Ce sera cette marque/valeur que les nœuds internes de votre domaine DiffServ regarderons pour déterminer quel comportement ou niveau de qualité de service appliquer.

Comme vous pouvez le déduire, les Services Différenciés impliquent un domaine sur lequel toutes les règles DS devront être appliquées. Vous pouvez raisonner de la façon suivante : « Je classifierai tous les paquets entrant dans mon domaine. Une fois qu'ils seront entrés dans mon domaine, ils seront soumis aux règles que ma classification impose et chaque nœud traversé appliquera son niveau de qualité de service ».

En fait, vous pouvez appliquer vos propres politiques dans vos domaines locaux, mais des autorisations au niveau service devront être considérées lors de la connexion à d'autres domaines DS.

En ce moment, vous vous posez peut-être beaucoup de questions. DiffServ est plus vaste que ce que j'ai expliqué. En fait, vous pouvez comprendre que je ne peux pas résumer plus de trois RFC en 50 lignes :-).

Comme le spécifie la bibliographie concernant DiffServ, nous différencions les nœuds frontaliers et les nœuds intérieurs. Ce sont deux éléments importants dans le chemin qu'emprunte le trafic. Les deux réalisent une classification quand un paquet arrive. Le résultat peut être utilisé à différents endroits lors du processus DS avant que le paquet ne soit libéré vers le réseau. Cela est possible car le nouveau code DiffServ fournit une structure appelée sk_buff, incluant un nouveau champ appelé skb->tcindex. Ce champ mémorisera le résultat de la classification initiale et pourra être utilisé à plusieurs reprises dans le traitement DS.

La valeur skb->tc_index sera initialement configurée par le gestionnaire de mise en file d'attente DSMARK. Cette valeur sera extraite du champ DS de l'en-tête IP de tous les paquets reçus. En outre, le classificateur cls_tcindex lira tout ou une partie de la valeur skb->tcindex et l'utilisera pour sélectionner les classes.

Mais, avant tout, regardons la commande qdisc DSMARK et ses paramètres :

... dsmark indices INDICES [ default_index DEFAULT_INDEX ] [ set_tc_index ]

Que signifient ces paramètres ?

Regardons DSMARK procéder.

Ce gestionnaire de mise en file d'attente réalisera les étapes suivantes :

                         skb->ihp->tos
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >
     |                                                       |     ^
     | -- Si vous déclarez set_tc_index, nous configurons    |     |  <-----Peut changer
     |    la valeur DS dans la variable skb->tc_index        |     |O       le champ DS
     |                                                      A|     |R
   +-|-+      +------+    +---+-+  File d'attente-+     +---N|-----|----+
   | | |      |filtre|--->|   | |-->  . . .  -->| |     |   D|     |    |
   | | |----->|  tc  |--->|   | |   interne     | |---->|    v     |    |
   | | |      |index |--->| | | +---------------+ |   ---->(masque,valeur)|
-->| O |      +------+    +-|-+--------------^----+  /  |  (.  ,  .)    |
   | | |          ^         |                |       |  |  (.  ,  .)    |
   | | +----------|---------|----------------|-------|--+  (.  ,  .)    |
   | | sch_dsmark |         |                |       |                  |
   +-|------------|---------|----------------|-------|------------------+
     |            |         | <- tc_index -> |       |
     |            |(lecture)|   peut changer |       |  <--------------Index de la table
     |            |         |                |       |                    des couples
     v            |         v                v       |                    (masque,valeur)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ->
                         skb->tc_index

Comment faire le marquage ? Il suffit de modifier le masque et la valeur associés à la classe que vous voulez marquer. Regardez la ligne de code suivante :

tc class change dev eth0 classid 1:1 dsmark mask 0x3 value 0xb8

Cela modifie le couple (masque,valeur) dans la table de hachage, et re-marque les paquets appartenant à la classe 1:1. Vous devez "changer" ces valeurs en raison des valeurs par défaut que le couple (masque, valeur) obtient initialement (voir le tableau ci-dessous).

Nous allons maintenant expliquer comment le filtre TC_INDEX travaille, et comment il s'intègre dans tout cela. En outre, le filtre TC_INDEX peut être utilisé dans des configurations autres que celles incluant les services DS.

Voici la commande de base pour déclarer un filtre TC_INDEX :

... tcindex [ hash SIZE ] [ mask MASK ] [ shift SHIFT ]
            [ pass_on | fall_through ]
            [ classid CLASSID ] [ police POLICE_SPEC ]

Ensuite, nous montrons l'exemple utilisé pour expliquer le mode opératoire de TC_INDEX. Soyez attentif aux mots en gras : tc qdisc add dev eth0 handle 1:0 root dsmark indices 64 set_tc_index tc filter add dev eth0 parent 1:0 protocol ip prio 1 tcindex mask 0xfc shift 2 tc qdisc add dev eth0 parent 1:0 handle 2:0 cbq bandwidth 10Mbit cell 8 avpkt 1000 mpu 64 # Classe du trafic EF tc class add dev eth0 parent 2:0 classid 2:1 cbq bandwidth 10Mbit rate 1500Kbit avpkt 1000 prio 1 bounded isolated allot 1514 weight 1 maxburst 10 # Gestionnaire de file d'attente fifo pour le trafic EF tc qdisc add dev eth0 parent 2:1 pfifo limit 5 tc filter add dev eth0 parent 2:0 protocol ip prio 1 handle 0x2e tcindex classid 2:1 pass_on (Ce code n'est pas complet. Ce n'est qu'un extrait de l'exemple EFCBQ inclus dans la distribution iproute2).

Avant tout, supposons que nous recevons un paquet marqué comme EF. Si vous lisez le RFC2598, vous verrez que DSCP recommande une valeur de 101110 pour le trafic EF. Cela signifie que le champ DS sera égal à 10111000 (rappelez- vous que les bits les moins significatifs de l'octet TOS ne sont pas utilisés dans DS) ou 0xb8 en notation hexadécimale.

              FILTRE
              TC INDEX
   +---+      +-------+    +---+-+    +------+                +-+    +-------+
   |   |      |       |    |   | |    |FILTRE|  +-+    +-+    | |    |       |
   |   |----->| MASK  | -> |   | | -> |HANDLE|->| |    | | -> | | -> |       |
   |   |  .   | =0xfc |    |   | |    |0x2E  |  | +----+ |    | |    |       |
   |   |  .   |       |    |   | |    +------+  +--------+    | |    |       |
   |   |  .   |       |    |   | |                            | |    |       |
-->|   |  .   | SHIFT |    |   | |                            | |    |       |-->
   |   |  .   | =2    |    |   | +----------------------------+ |    |       |
   |   |      |       |    |   |       CBQ 2:0                  |    |       |
   |   |      +-------+    +---+--------------------------------+    |       |
   |   |                                                             |       |
   |   +-------------------------------------------------------------+       |
   |                          DSMARK 1:0                                     |
   +-------------------------------------------------------------------------+

Le paquet arrive alors avec la valeur du champ DS configurée à 0xb8. Comme je l'ai expliqué auparavant, le gestionnaire de mise en file d'attente dsmark, identifié par 1:0 dans cet exemple, récupère le champ DS et l'enregistre dans la variable skb->tc_index. L'étape suivante consistera à associer un filtre à ce gestionnaire de mise en file d'attente (la seconde ligne dans cet exemple). Les opérations suivantes seront réalisées :

Valeur1 = skb->tc_index & MASK
Clé = Valeur1 >> SHIFT

Dans cet exemple, MASK=0xFC et SHIFT=2.

Valeur1 = 10111000 & 11111100 = 10111000
Clé = 10111000 >> 2 = 00101110 -> 0x2E en hexadécimal

La valeur retournée correspondra à un identificateur de filtre du gestionnaire de file d'attente interne (dans l'exemple, identifier par 2:0). Si un filtre avec cet identificateur (id) existe, les conditions de contrôle et de performance seront vérifiées (au cas où le filtre inclurait ceci) et l'identificateur de classe sera retourné (dans notre exemple, classid 2:1) et stocké dans la variable skb->tc_index.

Si aucun filtre avec cet identificateur n'est trouvé, le résultat dépendra de la déclaration de l'option fall_through. Si tel est le cas, la valeur Clé est retournée comme identificateur de classe. Si cela n'est pas le cas, une erreur est retournée et le traitement continue avec les filtres restant. Faites attention si vous utilisez l'option fall_through ; ceci ne peut être fait que si une relation existe entre les valeurs de la variable skb->tc_index et les identificateurs de classe.

Les derniers paramètres à commenter sont hash et pass_on. Le premier est relié à la taille de la table de hachage. Pass_on sera utilisé pour indiquer d'essayer le filtre suivant dans le cas où aucun identificateur de classe égal au résultat du filtre ne serait trouvé. L'action par défaut est fall_through (regarder la table suivante).

Finalement, regardons quelles sont les valeurs possibles pour la configuration de tous ces paramètres TCINDEX :

Nom TC                  Valeur          Défaut
-----------------------------------------------------------------
Hash                    1...0x10000     Dépendant de l'implémentation
Mask                    0...0xffff      0xffff
Shift                   0...15          0
Fall through / Pass_on  Flag            Fall_through
Classid                 Major:minor     Rien
Police                  .....           Rien

Ce type de filtre est très puissant. Il est nécessaire d'explorer toutes les possibilités. En outre, ce filtre n'est pas seulement utilisé dans les configurations DiffServ. Vous pouvez l'utiliser comme n'importe quel autre filtre.

Je vous recommande de regarder les exemples DiffServ inclus dans la distribution iproute2. Je vous promets que j'essaierai de compléter ce texte dès que possible. Tout ce que j'ai expliqué est le résultat de nombreux tests. Merci de me dire si je me suis trompé quelque part.