Mod` ele DiffServ*

La file d’attente de la classe i est stable si

ρi < 1 ⇒

λiLi

Ci

< 1 (2.3)

2.2 Mod`ele DiffServ*

Bas´e sur l’architecture DiffServ, DiffServ* est un mod`ele propos´e par [3] pour prot´eger les trafics de haute priorit´e contre les congestions et les pannes de la couche optique et garantir ainsi leur qualit´e de service dans les r´eseaux maill´es optiques lorsqu’une rupture de cˆables survient. L’objectif de ce projet est d’impl´ementer le mod`ele DiffServ* dans les r´eseaux maill´es sans fil. Dans cette section, nous expliquons le mod`ele DiffServ* tel qu’il a ´et´e pens´e pour les r´eseaux optiques puis nous pr´esentons l’adaptation propos´ee pour les r´eseaux sans fil.

2.2.1 DiffServ* dans les r´eseaux IP/WDM

Dans les r´eseaux filaires et optiques, la qualit´e du canal de transmission est une variable `a deux ´etats. Lorsque le canal est bon, tous les paquets sont envoy´es `a d´ebit constant. Lorsque le canal est mauvais, aucun paquet ne peut ˆetre transmis car le d´ebit est nul. Ainsi, s’il existe un unique chemin entre une source de trafic et sa destination, la diff´erenciation offerte par DiffServ prend fin lorsqu’une d´efaillance apparaˆıt sur un des supports de transmission. Cela se traduit tout simplement par un arrˆet complet du service. De plus, l’apparition d’une panne affecte de la mˆeme fa¸con toutes les classes de service, de sorte qu’elles subissent toutes une d´e- gradation de performance. Cependant, en utilisant plusieurs chemins disjoints entre la source et la destination, comme le fait DiffServ*, l’apparition d’une panne sur l’une quelconque des routes n’entraˆıne pas la suspension totale du service mais simplement une diminution de la largeur de bande disponible. D`es lors, le m´ecanisme de contrˆole de congestion de DiffServ* se d´eclenche et ajuste le d´ebit de transmission par classe de fa¸con `a prot´eger les trafics priori- taires contre toute d´egradation de performance. DiffServ* permet ainsi de garantir la qualit´e de service des trafics prioritaires et ce, mˆeme en cas de panne dans la couche optique. Avec

DiffServ*, la d´egradation de performance des trafics prioritaires peut seulement ˆetre caus´ee par une interruption compl`ete du service, interruption qui ne peut avoir lieu que si toutes

les routes vers la destination tombent en panne au mˆeme moment, chose assez rare dans les r´eseaux filaires. La mise en œuvre de DiffServ* n´ecessite donc une r´epartition de la charge entre plusieurs canaux et un m´ecanisme de d´etection de panne.

Par ailleurs, il faut souligner que le fonctionnement de DiffServ* repose enti`erement sur le concept de lien logique. Un lien logique entre deux nœuds est constitu´e d’un regroupement de plusieurs liens physiques entre ces 2 nœuds. En outre, un lien logique peut ˆetre port´e par un chemin de plusieurs liens physiques.

2.2.2 DiffServ* dans les r´eseaux 802.11

Dans les r´eseaux sans fil, la qualit´e du canal n’est plus une variable binaire mais elle d´epend de la valeur du rapport signal sur bruit (SNR). Dans cet environnement, lorsque le canal est mauvais, le d´ebit de transmission n’est pas nul mais diminue en fonction du SNR. Plus le SNR diminue, plus le d´ebit de transmission diminue aussi. De plus, la r´eduction de bande passante n’est plus due `a une rupture de cˆable mais `a des ph´enom`emes multiples tels l’interf´erence, le bruit, la distance entre ´emetteur et destination, ou encore la vitesse de d´eplacement des stations. L’adaptation de DiffServ* dans les r´eseaux sans fil requiert donc une mod´elisation du canal sans fil pour mettre en ´evidence la r´eduction de bande passante engendr´ee par les “pannes” et la d´etermination de plusieurs chemins ind´ependants entre la source et la destination. Dans un environnement sans fil, les “pannes” repr´esentent la qualit´e du canal.

Les modifications requises pour impl´ementer DiffServ* dans les r´eseaux sans fil nous ont permis de proposer une nouvelle architecture pour chaque nœud. En effet, cette variante de DiffServ*, que nous nommons Wireless-DiffServ*, est un m´ecanisme multi-couche qui in- teragit avec les couches IP, MAC et PHY afin de garantir la qualit´e de service des trafics hautement prioritaires dans un environnement sans fil variable. Les m´ecanismes de diff´eren- ciation de la couche IP doivent recevoir des couches MAC et PHY une information portant sur l’´etat du m´edia sans fil afin de r´eajuster l’ordonnancement des paquets de mani`ere `a limiter les d´egradations de qualit´e de service des trafics prioritaires.

L’architecture propos´ee sur la figure 2.2 montre les composants principaux de chaque couche. Ainsi, le classificateur de paquet, les files d’attente, de mˆeme que l’ordonnanceur DiffServ sont mises en place avant le bloc de routage. Le bloc de routage, quant `a lui, choisit l’interface de sortie vers laquelle le paquet doit ˆetre envoy´e en fonction du routage sur les diff´erents chemins vers la destination. Chaque nœud est ´equip´e d’au moins trois interfaces radio. Il est `a noter que Wireless-DiffServ* utilise le mˆeme principe de fonctionnement que DiffServ c’est-`a-dire la mˆeme classification de trafic et les mˆemes politiques d’ordonnancement que DiffServ. Remarquons que l’architecture propos´ee peut ˆetre d´eploy´ee avec une seule

Voix Routage MAC 1 MAC 2 MAC 3 CH 1 CH 2 CH 3 DiffServ Paquets entrants MAC Etat Vidéo Données IP

Figure 2.2 Protection DiffServ* dans un nœud mesh

interface. Dans ce cas, il n’y aurait aucune diff´erence entre le mod`ele DiffServ standard et le Wireless-DiffServ*. Dans les sections qui suivent, nous expliquons le mod`ele utilis´e pour mettre en ´evidence la qualit´e du canal sans fil puis nous pr´esentons le fonctionnement du module de routage.