5th International Conference: Sciences of Electronic, Technologies of Information and Telecommunications March 22-26, 2009 TUNISIA

SETIT 2009

tude et valuation des Performances des Mcanismes de Contrle de Congestion pour les Rseaux Metro Ethernet
Maha BOUAZIZ*, Hni KAANICHE ** et Lotfi KAMOUN*
*

Laboratoire dlectronique et des Technologies de lInformation (LETI), ENIS, Sfax- TUNISIE

Maha.bouaziz@gnet.tn Lotfi.Kamoun@isecs.rnu.tn
**

Laboratoire CRISTAL, ENSI, Universit de Manouba, 2010 Manouba-Tunis, TUNISIE

Heni.kaaniche@tunet.tn

Rsum: En quelques annes, le rseau informatique est devenu une ressource ncessaire tous les domaines. Metro Ethernet est un nouveau type de rseau informatique, qui est dploy pour les zones mtropolitaines. Ce type de rseau a plusieurs avantages tels que la simplicit, laccs haut dbit et le cot de dploiement. Mais, vu limportance dutilisation de ce rseau, un problme majeur qui se pose, celle de la congestion qui rduit les performances du rseau. Donc, pour assurer une utilisation efficace des ressources disponibles, les rseaux Metro Ethernet doivent tre contrls dune faon approprie pour viter la perte des donnes et maintenir de bonnes performances. Ainsi, il est souhaitable d'avoir un mcanisme de contrle de congestion pour prvenir les sources dajuster leurs taux de transfert selon ltat du rseau, pour liminer, sinon rduire la perte des donnes le maximum possible. Dans ce contexte, plusieurs mcanismes de contrle de congestion, qui suivent la norme IEEE 802.1Qau [WGP 08], ont t proposs tel que : Ethernet Congestion Manager (ECM), Quantized Congestion Notication (QCN), Quantized Ethernet Congestion Manager (QECM). Ce papier prsente une tude et une valuation des performances de ces mcanismes suite une srie de scnarii faites par le simulateur rseau Omnet. Ensuite, nous analysons et comparons les rsultats trouvs afin de dduire le meilleur mcanisme de contrle de congestion pour les rseaux Metro Ethernet. Mots cls: Metro Ethernet, congestion, contrle de congestion, ECM, QCN, QECM, IEEE 802.1Qau, Omnet.

INTRODUCTION
Les applications des rseaux de communication sont de plus en plus en croissance. Laugmentation du nombre dutilisateurs, du trafic et de la demande de nouveaux services, ont stimul le dveloppement des nouvelles technologies et le dploiement des rseaux haut dbit tel que les rseaux Metro Ethernet. Mais cette croissance qui a caus pas mal de problmes de saturation, provoque la congestion au niveau des nuds du rseau. En effet, la congestion se produit quand un rseau possde une insuffisance de ressource (largeur de bande passante, capacit de stockage des routeurs), ainsi quelle peut tre provoque par la diffrence de la largeur de bande passante dun rseau autre. La congestion provoque la perte des donnes qui circule dans le rseau rduisant ainsi la qualit de service. Donc, pour assurer une utilisation efficace des ressources disponibles, Ces rseaux doivent tre suivis

par des mcanismes de contrle de congestion de faon approprie. Dans ce travail, nous nous intressons ltude et la simulation de quelques mcanismes de contrle de congestion pour les rseaux Metro Ethernet, afin de pouvoir comparer et valuer leurs performances. Ce papier est dcompos de quatre parties : La premire partie consiste introduire les rseaux Metro Ethernet. La deuxime prsente la congestion, ses causes et les diffrents mcanismes de contrle de congestion ainsi que leurs principes de raction contre les variations de ltat du rseau. Ensuite, Nous traitons les rsultats de simulation et nous valuons et comparons les performances de ces mcanismes. Finalement, nous clturons ce travail par une conclusion et des perspectives

1. Le rseau Metro Ethernet

Le rseau Metro Ethernet est un rseau de tlcommunication haut dbit bas sur le standard

-1-

SETIT2009 Ethernet qui couvre une zone gographique tendue. Ce type de rseau fournit diffrents services tels que les services aux entreprises, accs haut dbit pour le grand public, rseau de collecte des oprateurs mobiles etc. Il a t dvelopp par trois organismes de normalisation : MEF (Metro Ethernet Forum), ITU (International Telecommunication Union) et IEEE (Institute of Electrical and Electronics Engineers). L'objectif de son installation est de remplacer les composants SDH (Synchronous Digital Hierarchy) vu que ces composants sont plus complexes, leur cot de mise en place est cher. Par contre Les rseaux Ethernet sont plus flexibles et moins coteux que les composants SDH et les lignes loues. Ils peuvent supporter galement des dbits levs atteignant les GgatBits/s [MEF 06] [MAS 07]. De plus, Metro Ethernet peut tre facilement reli au rseau de client, d l'utilisation rpandue de l'Ethernet dans les rseaux de corporation. Parmi les services abondants en Metro Ethernet, on a le service point point (E-Line) qui correspond aujourd'hui la majorit des besoins, et le service multipoint--multipoint (E-LAN) [MEF 07]. Ces mcanismes sont bass sur deux entits : le point de congestion et le point de raction [HUG 07] : Le point de congestion (CP) : C'est une entit intgre un commutateur. Il a une identit appele CPID. Le CP prlve une trame chantillon parmi les trames entrantes puis il gnre un message de notification adress vers la source. Ce message gnr contient des informations concernant ltat de la file dattente du commutateur. Le point de raction (RP) : C'est une entit intgre un limiteur de taux li la source, et cest celui qui reoit le message de notification. Le RP ajuste son taux de transfert en se basant sur les informations reues du CP. On aura une association entre le CP et le RP en cas o la notification demande une diminution du taux de transfert, et le RP naugmente le taux seulement s'il reoit un signal d'augmentation d'un CP associ lui, sinon il ne fait rien [ITG 07].

2.1. Contrle de congestion par le mcanisme ECM (Ethernet Congestion Manager) La file dattente du commutateur contient trois seuils : le seuil dquilibre Qeq, le seuil de la congestion dlicat Qmc et le seuil de la congestion extrme Qsc.

Figure 1. La topologie MAC in MAC pour les rseaux Metro Ethernet Le protocole de communication utilis est (MAC in MAC), qui repose sur des extensions de la technologie Ethernet. Ce protocole est utilis principalement dans les segments daccs et mtropolitain des rseaux de nouvelle gnration des fournisseurs de services de tlcommunications. MAC in Mac est spcifi dans la norme IEEE 802.1ah [PAU 05], il fournit un modle d'interconnexion pour les domaines (Q in Q) dfini dans la norme IEEE 802.1ad, celui-ci fournit un modle dinterconnexion des rseaux virtuel (VLAN) dfini par le standard IEEE 802.1Q [STE 07, NOR 07, DAV 08].

Figure 2. Dtection de la congestion et gnration du message de notification Le but global du mcanisme de contrle de congestion est de tenir l'occupation de la file dattente au niveau du seuil dquilibre. Ceci est ralis en ajustant le bon taux de transfert de la source laide dune valeur de rtroaction Fb [DAV 07a] [DAV 07b]. Fb est calcul en utilisant deux valeurs proportionnelles, le dcalage par rapport au niveau dquilibre Qoff et le taux de changement de la file d'attente Q. Le point de congestion prend une trame chantillon parmi les trames entrantes, et daprs cet chantillon il compare la longueur de la file dattente Q avec les trois seuils Qsc, Qmc, Qeq [YI 07], donc si: Q > Qsc : dans ce cas, il sagit dune Congestion svre, ainsi le RP reoit une trame de notification grave ECM (0.0) pour ajuster le dbit 0 Mbit/s pour un instant choisit alatoirement. Qmc < Q < Qsc : dans ce cas, il sagit dune Congestion dlicat, ainsi le CP envoie une trame appel ECM-Max pour une diminution maximale

2. Le contrle de congestion pour les rseaux Metro Ethernet

Les mcanismes de contrle de congestion traits dans ce papier suivent la norme IEEE 802.1Qau. Ils sont bass sur le principe de notification, cest dire informer la source pour ragir avant la production de la congestion afin de pouvoir ajuster le bon taux de transfert selon la disponibilit des ressources soutenues. La notification peut tre pour rduire le dbit en cas de saturation du rseau, ou bien pour laugmenter quand les ressources du rseau sont soulages, afin dassurer une meilleure exploitation de la bande passante disponible.
-2-

SETIT2009 du taux de transfert. Qeq < Q < Qmc : dans ce cas, le CP calcule les deux valeurs proportionnelle Qoff et Q. Puis il envoie une trame contenant ces deux valeurs ECM(Qoff, Q). Q < Qeq : dans ce cas, le CP vrifie sil est associ avec le RP de la source qui a envoy la trame. Si cest le cas, il lui envoie une trame de notification ECM(Qoff, Q) pour augmenter le dbit, sinon il n'envoie aucun signal. La figure La figure 3 prsente la variation du dbit de transfert en fonction du temps.

Le point de raction contient plusieurs limiteurs de taux pour chaque flux. En recevant le message de notification, il calcule la valeur de rtroaction laide des paramtres envoys : Fb = (Qoff + w Q) O w est un paramtre de poids. Qoff = Q Qeq Q = Q Qold (2) (3) (1)

Figure 3. Variation du dbit de transfert pour QCN La variation du dbit de transfert passe par trois phases: Rduction multiplicative : Dans ce cas, le point de raction rduit son dbit de transfert vers Rnew quand il reoit un message de notification du CP : Rnew = R Rd Rd = R |FB| Gd (6) (7)

O Qold est la valeur de la file d'attente l'instant de prlvement de lchantillon prcdent. L'ajustement du taux de transfert suit le principe d'AIMD (Additive Increase Multiplicative Decrease) selon la valeur de rtroaction Fb [DAV 05], donc si : Fb < 0 : Le RP effectue une diminution multiplicative et modifie son taux de transfert courant R : R = R (1 Gd|FB|) O Gd est le gain de diminution. Fb > 0 : Le RP effectue une augmentation additive en cas dexistence dune association entre le RP et le CP et modifie son taux de transfert courant R : R = R + Gi.Fb.Ru (5) (4) -

Tel que Rd est la quantit de rduction du dbit. Puis, RP passe vers la deuxime phase. Recouvrement rapide : Cette phase est compose de cinq cycles. Le passage d'un cycle un autre se fait selon le nombre doctets des trames dans la file dattente de la source envoyer. Le taux de transmission pendant le cycle K est : Rk = Rnew + Rd/2 + Rd/4 + + Rd/(2^k) (8)

Pendant ces cycles de recouvrement rapide, si le RP reoit un autre message de notification dun signal de diminution, alors la phase est arrte et le mcanisme reprend ds le dbut par la premire phase. Augmentation active: Cette phase suit le recouvrement rapide par le mme principe de la phase prcdente, sauf que le taux est augment par une quantit Ri (constante). De mme, cette phase est arrte et reprend ds le dbut en cas de recevoir un autre message de notification dun signal de diminution.

O Gi est le gain daugmentation et Ru est une constante qui donne les units correctes de taux. 2.2. Le contrle de congestion par le mcanisme QCN (Quantized Congestion Notification) Ce mcanisme prsente des amliorations par rapport ECM afin de rsoudre certaines issues. Les modifications concernent dune part la simplicit du mcanisme, il n'oblige pas l'association entre le point de congestion et le point de raction donc il peut fonctionner avec un seul limiteur de taux cest dire que tout le flux est orient vers le mme limiteur qui devient un multi-flux [ABD 07]. Dautre part, les modifications concernent un autre principe de raction contre les messages de notification pour avoir des bonnes performances. Le point de congestion calcule la valeur de rtroaction Fb par la mme quation utilise pour ECM puis il nenvoie que les valeurs ngatives de Fb, les autres sont rejetes [RON 07], [RAJ 07] et [GUE 07].
-3-

2.3. Le contrle de congestion par le mcanisme QECM (Quantized Ethernet Congestion Manager) Le mcanisme de contrle de congestion QECM est une hybridation des deux mcanismes prcdents ECM et QCN [DAV 07c]. Ce mcanisme hrite les avantages de ces deux mcanismes [GUS 07]. Le point de congestion gnre les deux types de rtroaction. Les messages de rtroaction ngative sont traits par le mme principe que QCN. Laugmentation pour lautre type de messages se fait en sautant un autre cycle de recouvrement rapide ou d'augmentation active.

SETIT2009

3. Analyse et valuation des performances

3.1. Simulation du rseau sans introduction de mcanisme de contrle de congestion Nous avons effectu une simulation dun rseau constituant trois nuds sources mettant chacun un flux de donnes passant par un commutateur et se dirigeant vers le mme nud destinataire. Aucun mcanisme de contrle de congestion nest implment.

Pour une simulation dun rseau sans contrle de congestion, le nombre de trame perdu est 300 trames pendant 0,177 seconde daprs la figure 5. (b). La perte commence de 0.068 seconde daprs la figure 5. (a), cest linstant o la quantit doctets dans la file dattente du commutateur atteint la capacit maximale. Donc partir de cet instant, les trames ne seront pas tous servies, il y aura des pertes de trames. Daprs ces deux courbes, pour chaque 0.05 seconde, il ya 150 trames qui arrivent la file dattente du commutateur. En adquation de temps entre ces deux courbes, partir de 0.068 seconde, on a 137 trames qui sont perdus et 13 trames qui sont servies parmi 150 trames. Donc en moyenne, on a 8.7% trames servie et 91.3% trames perdu. Ce qui est grave puisque la majorit des donnes sont perdu. Do, ces rsultats confirme la ncessit dintgrer un mcanisme de contrle de congestion pour anticiper contre cet issue et assurer une garanti denvoie des donnes.

Figure 4. Topologie dun rseau avec trois sources et un seul commutateur Les flux de donnes sont de type CBR 40 Mbit/s, dont la taille de trames est gale 1000 octets. Toutes les trames passent par le mme commutateur disposant dune file dattente de capacit 200 000 octets. Le dbit du commutateur est pris gal 100 Mbit/s. Pour ce cas, il est clair que la somme des dbits des trois sources dpasse le dbit support par le commutateur. Alors, les trames vont saccumuler dans la file dattente jusqu atteindre la capacit maximale de la file, et on aura une perte des trames.

3.2. Simulation des mcanismes de contrle de congestion pour diffrentes topologies Aprs lintgration des mcanismes de contrle de congestion ECM, QCN et QECM. Nous effectuons un ensemble de simulations diffrentes pour chaque mcanisme. Nous avons pris les valeurs indiques dans le tableau suivant. Tableau : Les valeurs des paramtres des diffrents scnarii ECM QCN QECM 200 000 octets 180 000 octets 120 000 octets 20 000 octets 1000 octets 100 Mbit/s 40 Mbit/s 4 1/128 2 Non appliqu 5Mbit/s 1Mbit/s Non appliqu

Taille file dattente Qeq Qmc Qsc Taille de la trame Dbit du commutateur Dbit de la Source Gain daugmentation Gi Gain de diminution Gd Poids W Dbit augment Ri Ru

3.2.1. Scnario 1 Ce scnario est effectu pour une topologie du rseau de la figure 4 constitu de 3 sources, un destinataire et un seul commutateur.

Figure 5. La variation de la file dattente et le nombre de trame perdu en fonction du temps

-4-

SETIT2009

Figure 7. Variation du nombre doctets dans la file dattente en fonction du temps pour chaque mcanisme du scnario 2 3.2.3. Scnario 3 Ce scnario est effectu pour une topologie plus complexe que prcdemment, constitue de plus quun commutateur.

Figure 6. Variation du nombre doctets dans la file dattente en fonction du temps pour chaque mcanisme du scnario 1 3.2.2. Scnario 2 Pour ce scnario, nous avons augment le nombre de source 30 sources envoyant des donnes vers le mme destinataire passant par un seul commutateur. Figure 8. Topologie dun rseau complexe avec six sources et 4 commutateurs

-5-

SETIT2009 du nombre doctets dans la file dattente pour QECM possde des faibles oscillations autour du niveau du seuil dquilibre. Pour QCN et ECM, la variation du nombre doctets dans la fille dattente oscille aussi au niveau du seuil dquilibre mais elle possde des fortes oscillations perturbes. Par exemple, daprs les courbes du scnario 2, le nombre doctets dans la file atteint 50000 octets pour ECM et 40000 octets pour QCN, alors pour QECM, il na pas dpass les 30000 octets. Et daprs les courbes du scnario 3, il a atteint environ 73000 octets pour ECM et QCN et seulement 33000 octets pour QECM. La stabilit par le mcanisme ECM est mal maintenue. La quantit en octets dans la file dattente descend des faibles valeurs, elle vaut 0 octets daprs les figures 7 et 9 (une file vide), puisquen cas de diminution du dbit et du nombre doctets dans la file, on a un recouvrement trs lent. Car ECM suit le principe daugmentation additive (linaire) du dbit qui est un peu lente. De plus, il naugmente le dbit que suite la rception dun signal. Par contre pour les deux autres mcanismes, le principe du recouvrement est mieux. Lorsquil y a une diminution du dbit en cas dun signal de diminution, le mcanisme passe directement et immdiatement vers une phase de recouvrement petit petit. Il nattend pas quil y aura un signal daugmentation pour quil intervienne, il ragit directement suite toute diminution. Pour cette raison, la quantit en octets dans la fille dattente naura pas de trs faibles valeurs. Elle atteint 10000 octets pour QCN et 17000 octets pour QECM daprs la figure 7 et 9. Malgr que le principe de recouvrement est le mme pour les deux mcanismes QCN et QECM, on trouve par simulation que QECM est plus stable. Daprs les rsultats des trois scnarii, la quantit en octets dans la file dattente pour QECM est presque au mme niveau que le seuil dquilibre. Pour QCN, le recouvrement est un peu lent, cela sexplique par son manque de rtroaction positif. QECM dont elle hrite le principe de QCN en ajoutant la gnration de rtroaction positive prouve cela. Lorsquil y a une diminution du dbit (diminuer le nombre de trame envoy vers la fille dattente des commutateurs), le mcanisme QECM ragit rapidement pour augmenter le dbit proportionnellement au besoin de la file dattente, et dans le but de conserver un nombre doctets presque stable dans la file dattente au niveau de lquilibre.

Figure 9. Variation du nombre doctets dans la file dattente en fonction du temps pour chaque mcanisme du scnario 3 3.3. Interprtation des rsultats 3.3.1. Etude de la perte des trames Daprs les courbes dresses ci-dessus, nous remarquons quil ny a pas de perte de trames. Le nombre doctets dans la file dattente augmente au dbut, il atteint 170000 octets pour le scnario 2; 85000 octets pour le scnario 3, puis il diminue pour se stabiliser autour du seuil dquilibre. Contrairement, pour le cas de la simulation dun rseau sans contrle de congestion et daprs la figure 4. (a) la quantit doctets dans la file dattente augmente jusqu atteindre la capacit maximale de la file 200000 octets. Au del, les trames de donnes seront perdues (300 trames perdus pendant 0,177 seconde daprs la figure 5. (b)). Donc pour le cas du rseau avec un mcanisme de contrle de congestion, la diminution du nombre doctets dans la file dattente se fait par lintervention des mcanismes de contrle de congestion ECM, QCN et QECM qui oblige la rduction du dbits des sources et par consquent la rduction du nombre de trame reu par le commutateur. Le dbit est ajust selon ltat de la file dattente par rapport aux valeurs des trois seuils Qeq, Qmc et Qsc. Si le nombre doctets dans la file dpasse Qeq, les sources doivent diminuer le dbit de transfert. Si elle atteint Qmc, a veut dire que le rseau est en tat de congestion dlicate, donc on doit faire une diminution maximale, et sil atteint Qsc, alors il y a une congestion svre donc le transfert sera temporairement arrt afin de pouvoir soulager la file dattente et rduire la perte des trames. Do, la ncessit dintgrer un mcanisme de contrle de congestion pour viter ou diminuer la perte des trames le maximum possible. 3.3.2. Etude de la stabilit La stabilit cest la conservation du nombre doctets dans la file dattente au niveau du seuil dquilibre Qeq. Daprs les figures 6, 7 et 9, la stabilit est maintenue pour les trois mcanismes, et elle est mieux pour le mcanisme QECM que pour les deux autres mcanismes pour les diffrents scnarii. La variation
-6-

SETIT2009 laugmentation du nombre des commutateurs (scnario 3), la stabilit reste conserve avec une perturbation des oscillations qui deviennent plus fortes par rapport une simple topologie, entre 17 octets et 33000octets. Le changement de la topologie du rseau, ne modifie pas donc trop la stabilit de la quantit doctets dans la file dattente pour les trois mcanismes. Ces mcanismes peuvent tre donc scalables pour des rseaux tendus. 3.3.4. Etude de lquitabilit La figure 11 prsente la variation du dbit de transfert en fonction du temps pour le scnario 1 (trois sources et un seule commutateur) pour chaque mcanisme.

Figure 10. Variation du dbit dune mme source pour les trois mcanismes Cette figure montre lallure du recouvrement du dbit dune source pour chaque mcanisme. Il est remarquable que laugmentation du dbit pour QECM est plus rapide (0.007 seconde) par rapport au mcanisme QCN (0.014 seconde) et au mcanisme ECM (0.011 seconde). Ds la rception dun message de signalisation ECM, la source rduit son dbit 8 Mbit/s. Et elle ne laugmente que si elle reoit un signal daugmentation. Pour cela, quelle a de passe par de faible dbit pour une priode. Par contre, pour le cas de QCN et de QECM, les sources augmentent le dbit de leurs flux de donnes immdiatement ds quils le baissent. Les courbes (a) et (b) de la figure 10 montrent une optimisation rapide du dbit des flux de donnes pour exploiter plus efficacement les capacits du commutateur. Nous pouvons conclure donc que la stabilit pour QECM est mieux, vient ensuite le QCN, puis ECM. 3.3.3. Etude de la scalabilit La scalabilit : cest le fait dtudier les performances de rseau en augmentant sa taille en termes de nombre de sources et de commutateurs. Daprs les rsultats des trois scnarii, en augmentant le nombre des sources (30 sources) pour le scnario 2, Les mcanismes de contrle de congestion conservent la stabilit du nombre doctets dans la file dattente au voisinage du seuil dquilibre Qeq, mais avec une augmentation des oscillations autour du seuil dquilibre. Par exemple, daprs la figure 6, pour une simulation par trois sources, les oscillations pour QECM sont entre 25000 octets et 18000 octets. Par contre, le cas du 30 sources dans la figure 7, les oscillations sont entre 30000 octets et 17 octets. De mme, en modifiant la topologie par
-7-

Figure 11. Variation du dbit de transfert des trois sources pour les diffrents mcanismes Pour avoir une quitabilit dans le rseau, il faut que les nuds sources partagent la bande passante de la mme faon. La figure prcdente montre que pour le mcanisme ECM, le dbit des flux de donnes pour les sources nest pas quitable. Par exemple, t=0.024s la source D possde un dbit gale 100 Mbit/s, par contre, pour les autres sources le dbit est lentour de 8 Mbit/s. De mme pour le mcanisme QCN, lquitabilit nest pas maintenue. Mais, la diffrence de dbit entre

SETIT2009 les diffrentes sources nest pas trs grande. Par exemple, t=0.04s, le dbit de la source B est gale 69 Mbit/s, celle de la source D est gale 20000 Mbit/s et pour la source A est gale 10000 Mbit/s. Pour le mcanisme QECM, lquitabilit est aussi nest pas maintenue, mais acceptable. Les dbits des diffrentes sources sont diffrents mais proches sauf une exception dans lintervalle de temps entre 0.07seconde et 0.1 seconde. Nous pouvons conclure que lquitabilit pour les trois mcanismes nest pas bien maintenue. Mais elle est meilleure pour QECM. l'organisation stratgique des normes Nortel Tlcoms pour ses conseils et aides prcieux la ralisation de ce travail.

REFERENCES
[ABD 07] Abdul Kabbani, Rong Pan, Balaji Prabhakar, Ashvin Laxmikantha, Mick Seaman QCN: transience, equilibrium, implementation, Meeting. [DAV 05] Davide Bergamasco (Cisco), Data Center Ethernet Congestion Management: Backward Congestion Notification, IEEE 802.1 Interim Meeting, Berlin Germany, Mai 2005. [DAV 07a] Davide Bergamasco (Cisco),Ethernet Congestion Manager, initial Draft, May 2007. [DAV 07b] Davide Bergamasco (Cisco),Ethernet Congestion Manager, IEEE 802 Plenary Meeting, Orlando, FL, Mars 2007. [DAV 07c] Davide Bergamasco, QCN: Problems, Solutions, and a Convergence Proposal, IEEE 802.1 Inetrim Meeting, Stockholm, Sweden, 2007. [DAV 08] Dave Allan, Metro Ethernet Convergence Toolkit Nortel, fev 2008. [GUE 07] Guenter Roeck, Teak Technologies, Congestion Management Protocols: More QCN Simulation Results, Meeting, Juillet 2007. [GUS 07] M. Gusat, C. Minkenberg, G. Roeck, Closed Loop CM w/ Probing QECM-(S)P, Meeting Octobre 2007. [HUG 07] Hugh Barrass (Cisco), Quality of service for unbounded data streams Joint ITU-T/IEEE Workshop, Juin 2007. [ITG 07] Interworking Task Group, Congestion Management, draft standard for local and metropolitan area networks, IEEE P802.1au/D0.2 Aot 2007. [MAS 07] Masahiro Maruyoshi Ethernet Protection Switching, Joint ITU-T/IEEE Workshop, Juin 2007. [MEF 06] MEF End-to-End Ethernet: Core, Metro, & Aggregation GLOBALCOMM2006, Oct 2006. [MEF 07] MEF Carrier Ethernet Services Overview Metro Ethernet Forum, Mars 2007. [NOR 07] Nortel PBT and the evolution of Ethernet, Customer Presentation, Oct 2007. [PAU 05] Paul Bottorff, IEEE 802.1ah Draft, Nortel, Mars 2005. [RAJ 07] Raj Jain, Jinjing Jiang, Chakchai So-In, Congestion Notification for Congestion Notification for Data Center Ethernet Networks: Key Principles IEEE 802.1au Meeting, San Francisco, Juillet 2007. [RON 07] Rong Pan, Laxmikantha, QCN Notification, Meeting. Balaji Prabhakar, Ashvin : Quantized Congestion

4. CONCLUSION ET PERSPECTIVES
Cette tude montre la ncessit davoir une intgration dun mcanisme de contrle de congestion pour les rseaux Metro Ethernet, afin davoir de bonnes performances en terme de stabilit, la scalabilit et taux de perte. Nous avons constat que les performances dECM ne sont pas bien satisfaisantes. Vu que le recouvrement du dbit est trs lent, ce qui cause une mauvaise stabilit cause des fortes oscillations au voisinage du seuil dquilibre. Do une mauvaise exploitation des ressources (cest dire quil arrive par fois que le nombre doctets dans de la file dattente est presque vide, alors que les sources sont encore en phase dattente denvoie). Les performances pour QCN sont meilleures quECM. Le principe de raction contre les messages de notifications est modifi, pour cela le recouvrement et la stabilit sont amliors. Mais malgr a, les performances ne sont pas encore optimales, vu le manque de rtroaction positif. Concernant le mcanisme QECM, dont il hrite les avantages des deux autres mcanismes (le principe de recouvrement de QCN et la gnration des deux types de rtroaction), nous constatons que ce mcanisme a bien intervenu contre la congestion, le recouvrement devient plus rapide (c'est--dire quil optimise les dbits des sources dune faon plus efficace que le ECM et le QCN), la stabilit de la file dattente est presque maintenue, il exploite bien les ressources disponibles ainsi que le nombre doctets dans la file est presque au niveau du seuil dquilibre. Le mcanisme QECM parait donc le meilleur mcanisme de contrle de congestion mais il n'a pas bien trait lquitabilit. Comme perspective de ce travail, une amlioration du mcanisme QECM peut tre propose afin davoir des performances meilleures notamment en terme dquitabilit. Une adaptation du mcanisme propos sera ncessaire et intressante pour le cas des rseaux Metro Ethernet ayant des topologies complexes et des congestions plus svres.

RECONNAISSANCE
Nous remercions monsieur Bilel JAMOUSSI, directeur de la technologie et responsable de
-8-

[STE 07] Stephen Haddock, Carrier Bridge Architecture, Joint ITU-T/IEEE Workshop, Juin 2007.

SETIT2009
[WGP 08] IEEE 802.1au Work Group Public Documents Repository, http://www.ieee802.org/1/pages/802.1au.html. [YI 07] Yi Lu, Rong Pan, Balaji Prabhakar, Davide Bergamasco, Valentina Alaria, Andrea Baldini, Congestion control in networks with no congestion drops, 2007.

-9-