| HOWTO du routage avancé et du contrôle de trafic sous Linux | ||
|---|---|---|
| Précédent | Chapitre 14. Gestionnaires de mise en file d'attente avancés & moins communs | Suivant |
Documents sources :
Exemples de la distribution iproute2.
White Paper-QoS protocols and architectures et Foires Aux Questions IP QoS, les deux par Quality of Service Forum.
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 par contre 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 noeud frontalier (noeud 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 noeuds 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 noeud 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 noeuds frontaliers et les noeuds 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 ?
indices : taille de la table des couples (masque,valeur). La valeur maximum est 2^n, où n>=0.
default_index : index d'entrée par défaut de la table si aucune correspondance n'est trouvée.
set_tc_index : indique au gestionnaire DSMARK de récupérer le champs DS et de l'enregistrer dans skb->tc_index.
Regardons DSMARK procéder.
Ce gestionnaire de mise en file d'attente réalisera les étapes suivantes :
Si vous avez déclaré l'option set_tc_index dans la commande qdisc, le champ DS est récupéré et mémorisé dans la variable skb->tc_index.
Le classificateur est invoqué. Celui-ci sera exécuté et retournera un identificateur de classe (class ID) qui sera enregistré dans la variable skb->tc_index. Si aucun filtre correspondant n'est trouvé, nous considérons l'option default_index comme étant l'identificateur de classe à enregistrer. Si, ni set_tc_index, ni default_index n'ont été déclarés, alors les résultats peuvent être non prédictifs.
Après avoir été envoyé dans le gestionnaire de file d'attente interne, où le résultat du filtre peut être réutilisé, l'identificateur de classe retourné par le gestionnaire est stocké dans la variable skb->tc_index. Cette valeur sera utilisée plus tard pour indexer la table masque-valeur. Le résultat de l'opération suivante sera assigné au paquet :
Nouveau_champ_DS = ( Ancien_champ_DS & masque ) | valeur |
La nouvelle valeur résultera donc d'un ET logique entre les valeurs du champ_DS et du masque, suivi d'un OU logique avec le paramètre valeur. Regardez la figure suivante pour comprendre tout ce processus :
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 |
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 utiliser 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 ] |
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.
| Précédent | Sommaire | Suivant |
| Algorithme Clark-Shenker-Zhang (CSZ) | Niveau supérieur | Gestionnaire de mise en file d'attente d'entrée (Ingress qdisc) |