Dans cette section, nous présentons une description détaillée du principe de fonctionne- ment de notre mécanisme, ainsi que des points essentiels pour son déroulement. Nous décrivons aussi, les différents champs de la table CT, ainsi que les types des différents messages échangés entre les serveurs CM voisins et leurs formats. Finalement, nous allons décrire notre proposition pour améliorer la sécurité des communications entre les différents éléments de l’architecture du mécanisme QoS-CMS.
4.2.1 Le principe de fonctionnement
L’idée de base de notre approche consiste à désigner dans chaque AS un serveur res- ponsable de la gestion des différentes classes de service, nommé le serveur Class Manager (CM). Dans ce serveur nous définissons une table, nommée Class Table (CT), qui contient toutes les informations concernant les différentes classes définies dans ce domaine (comme la bande passante, le taux de perte, le délai, etc.). Une fois que le serveur CM de chaque domaine remplit sa table CT, il l’envoie au domaine voisin. De cette façon, chaque serveur CM disposera de toutes les informations sur les classes de services définies dans le domaine voisin et pourra les diffuser vers tous les routeurs dans son domaine. Ainsi, lors de la ré- ception d’un paquet entrant du domaine voisin, le routeur de bordure dans le domaine courant peut le classer dans une classe de service qui a les mêmes caractéristiques que sa classe de service d’origine dans son domaine source. De cette manière, le trafic client conserve les mêmes contraintes de QoS au cours de son trajet vers sa destination, et reçoit le même traitement de bout en bout. Le schéma de la figure 4.1 résume ce mécanisme. Le fonctionnement de notre mécanisme suit les étapes du processus suivant :
1. Les routeurs reçoivent les trafics émis par les différents clients, et appliquent ensuite les différents algorithmes et mécanismes adoptés pour la gestion de la QoS en intra-domaine afin de classer ces trafics tout en respectant les contrats élaborés auparavant avec les clients (SLA).
2. Les routeurs envoient aux serveurs CM de leurs domaines toutes les informations sur les différentes classes qu’ils avaient créés pour classer les différents trafics clients.
3. Les serveurs CM établissent les tables de classe CT sur la base des informations reçues des routeurs. Ces tables contiennent toutes les informations sur chaque classe utilisée dans le domaine.
4. Les serveurs CM échangent leurs tables de CT.
À la fin de ce processus, les serveurs CM des différents domaines possèdent toutes les informations sur les classes de service de leurs voisins, et quand un routeur de bordure
Figure 4.1 – Le mécanisme de gestion de QoS en inter-domaines
reçoit un paquet venant du domaine voisin, il peut classifier ce paquet dans une classe qui a les mêmes propriétés que la classe définie dans son domaine source. De cette façon, le paquet circule dans le domaine adjacent dans les mêmes conditions du domaine source, et arrive à sa destination en satisfaisant les contraintes de QoS fixées dans le contrat établit avec son domaine source.
4.2.2 La classification en intra-domain
La première étape du processus de fonctionnement de notre mécanisme QoS-CMS est la classification du trafic émis par le client par le routeur d’entrée du domaine. Pour cela, chaque domaine peut mettre en œuvre le modèle de gestion de QoS en intra-domaine qui répond aux objectifs de sa politique QoS. Les trois modèles les plus utilisés pour assurer la QoS en intra-domain sont : IntServ, DiffServ et MPLS.
Ces trois modèles utilisent les en-têtes des paquets IP pour indiquer la classe de ser- vice à laquelle appartient chaque paquet. Ensuite, chaque classe de service est associée à un ensemble de paramètres de QoS qui correspondent aux besoins exigés par le service demandé.
En outre, le filtrage et l’attribution du trafic client aux classes de services correspon- dantes sont basés sur plusieurs paramètres en fonction de la politique de QoS mise en œuvre et du service demandé ; par exemple en fonction du type de l’application, du pro- tocole de transport utilisé ou même des adresses IP source et destination.
On note que, notre mécanisme QoS-CMS est indépendant du modèle de QoS im- plémenté en intra-domaine et peut ainsi être déployé quelque soit le modèle choisi par l’administrateur de l’AS. Ceci, permet d’augmenter la flexibilité et la simplicité de notre mécanisme, et constitue ainsi un avantage important pour les administrateurs des ASs.
4.2.3 La structure de la table CT
La table de classe CT est structurée selon les champs suivants :
1. Le numéro AS : pour identifier le domaine auquel appartient la classe de service. 2. Le numéro de classe : correspond à la valeur de l’étiquette qui identifie la classe de
service.
3. Bandwith : pour indiquer le pourcentage de bande passante attribué à la classe de
service.
4. Priority : pour spécifier le niveau de priorité de la classe de service.
5. Queue-limit : pour spécifier le nombre maximum de paquets que la file d’attente
peut contenir pour cette classe de service.
6. Random-detect : pour indiquer si l’algorithme WRED (Weighted random early de- tection) est activé sur cette classe de service.
On note que pour assurer une cohérence entre les tables CT des différents domaines, nous avons choisi dans notre mécanisme de ne définir dans la table CT que les paramètres communs entre les différents constructeurs, c’est-à-dire les paramètres de base utilisés par les différents constructeurs. Cependant, les champs de la table CT sont extensibles et peuvent être adaptés ultérieurement aux paramètres utilisés par le constructeur du matériel utilisé dans le réseau.
4.2.4 L’envoi des informations des routeurs au serveur CM
Comme on vient de mentionner, les routeurs reçoivent le trafic client et le classifient en appliquant les mécanismes du modèle de gestion de QoS en intra-domaine choisi. Les informations concernant les paramètres de chaque classe de service définie sur le routeur sont présentes dans son fichier de configuration. On propose alors que le routeur exécute un script qui permet d’extraire les informations relatives aux classes de service du fichier de configuration et les placer dans un nouveau fichier. Ce fichier sera envoyé au serveur CM. Une fois le serveur CM reçoit tous les fichiers des routeurs de bordure, il les regroupe dans un fichier nommé CT, qui représente la table de classes responsable du stockage des informations concernant toutes les classes de service définies dans le domaine. Notons qu’on préfère exécuter le programme pour traiter le fichier “start-up config” au niveau du routeur de bordure pour éviter toute vulnérabilité au niveau de la sécurité du réseau qui pourra se présenter si le fichier de configuration est envoyé en entier au serveur CM.
4.2.5 L’échange des tables CT entre les serveurs CM
Dans le mécanisme QoS-CMS, la communication entre tous les serveurs CM des différents domaines utilise le protocole TCP. Les informations échangées entre les serveurs CM
Figure 4.2 – Le format du message d’identification
Figure 4.3 – Le format du « Announcement message »
sont incluses dans des flux TCP. Alors, pour qu’un serveur CM puisse envoyer sa table CT au serveur CM du domaine voisin et recevoir la sienne, ils établissent d’abord une session TCP. Une fois la session TCP est établie, le premier message échangé entre les deux serveurs CM est le message d’identification, qui permet à chaque serveur CM de s’identifier vis-à-vis de son voisin, en envoyant son adresse IP et son numéro d’AS. Le format du paquet contenant le message d’identification est présenté dans la figure 4.2. Après l’identification, les serveurs CM échangent leurs tables CT en envoyant un ensemble de messages pour annoncer leurs classes de service, nommés « announcement messages ». Chaque message contient plusieurs valeurs des différents paramètres relatifs à chaque classe définie dans le domaine ; le format de chaque message est présenté dans la figure 4.3.
Les informations contenues dans chaque message une fois reçues par le serveur CM sont enregistrées dans sa table CT, de cette façon quand le serveur CM reçoit la totalité des messages, il aura toutes les informations concernant toutes les classes de service définies dans le domaine voisin.
Le dernier type de message est le message de mise à jour, qui est envoyé par un serveur CM quand il y a un ajout ou une modification d’une classe de service définie dans son domaine. Le message de mise à jour a le même format que le message d’annonce.
On note que, notre mécanisme se base essentiellement sur l’échange des tables CT entre les AS voisins, cela nécessite d’établir des accords entre ces ASs. En effet, les informations échangées entre les domaines dans les tables CT sont des informations très importantes et très sensibles et les administrateurs des domaines doivent négocier et établir un accord qui va gérer la relation entre les domaines pour que l’échange des tables CT se déroule sans problèmes. L’accord doit définir également comment l’échange des tables sera facturé.
4.2.6 La Diffusion des Tables CT
Une fois le serveur CM reçoit la table CT de son voisin, il la diffuse aux routeurs de son domaine. De cette façon tous les routeurs du domaine possèderont toutes les informations sur les classes de service définies dans le domaine voisin, et pourront utiliser ces infor- mations pour créer et configurer des classes de services qui auront les mêmes valeurs des paramètres de QoS. Ce qui permettra de classer les paquets arrivants du domaine voisin pour circuler dans le domaine courant avec les mêmes contraintes de QoS. Il est à noter que si le domaine voisin possède déjà une classe de service qui a les mêmes paramètres de QoS que la classe source, ce n’est pas nécessaire de créer une nouvelle classe, il suffira d’affecter le trafic client à la classe qui existe déjà. Aussi, si le nombre maximale de classes de service qu’on peut créer est atteint dans le domaine voisin, par exemple si on utilise DiffServ et on a déjà crée six classes, et on ne pourra donc pas créer de nouvelles classes, il suffit d’affecter le trafic client à la classe de service qui a les paramètres de QoS les plus proches de sa classe source.
4.2.7 L’implémentation du mécanisme
Concernant son implémentation le mécanisme QoS-CMS présente des avantages qui assurent une grande flexibilité et simplicité. En effet, d’une part l’implémentation de notre mécanisme ne nécessite pas une majeure mise à jour matérielle, comme il est le cas dans plusieurs autres méthodes, il suffit d’implémenter un serveur CM et d’insérer au niveau des routeurs un script qui permet d’envoyer les données vers le serveur CM. Ceci permet de réduire considérablement le coût matériel d’implémentation du mécanisme. D’autre part, selon le fonctionnement de notre mécanisme les opérations la construction des tables CT et leur échange entre les serveurs CM voisins ne sont effectuées qu’une seule fois après l’établissement de l’accord entre les AS ou bien, le cas échant, après un changement des classes de service définies dans un AS. Ce point présente également un avantage important puisque le coût de traitement (Overhead) est très limité.