Pfe Mansour Hana

8/7/2019 Pfe Mansour Hana

1/84

RAPPORT DE PROJET DE FIN DETUDES

Filire

Ingnieurs en Tlcommunications

Option

Ingnierie des Rseaux

Etude des mcanismes de diffrenciation

de services

Elabor par :

Hana MANSOUR

Encadr par :

M. Fakhreddine KHELIFA

M. Mounir FRIKHA

Anne universitaire : 2004/2005


2/84

i

Ddicace

A mes parents,A mes grands-parents,

A mes soeurs,A mes amis, particulirement, faker, Najet, Souheil, Rim,

Quils trouvent dans ce travail le fruit de leur patience

et du soutien permanent

quils mont prodigu pour affronter

tous les moments difficiles.

Hana


3/84

ii

Avant ProposLe travail prsent dans ce projet de fin dtudes a t effectu dans le cadre de la

prparation du diplme dingnieur en tlcommunications, option Ingnierie des Rseaux

(IRES) lEcole Suprieure des Communications de Tunis (SUPCOM).

Ce projet sinscrit dans le cadre dtude des mcanismes de diffrenciation de services et

la possibilit dintgration de lapproche de rgulation dynamique aux priorits des classes de

DiffServ.

Au terme de ce travail, nous tenons remercier tout particulirement :

M. Fakhreddine KHELIFA, mon encadrant, ingnieur au sein du CERT et M. Mounir

FRIKHA, mon encadrant, matre assistant SUPCOM, directeur du dpartement rseaux

lcole suprieure des communications de Tunis pour leur encadrement, leur disponibilit et

sympathie, pour les conseils quils mont prodigus et pour leur soutien moral.

Tous mes enseignants qui ont contribu ma formation ainsi quaux responsables de

SUPCOM et de CERT pour les moyens quils mont offert afin de mener terme ce travail.

Mes vifs remerciements sadressent aussi tous ceux qui mont encourag de prs ou de

loin tout au long de ce travail.


4/84

iii

RsumLe modle Diffrenciation de Services (DiffServ) ajoute des nouvelles fonctionnalits

aux routeurs afin damliorer la Qualit de Service. Des contraintes telles que la rduction du

dlai dacheminement ou le contrle dans la distribution de ressources peuvent tre satisfaites

grce aux mcanismes proposs par ce modle. A travers le comportement assur, le modle

DiffServ introduit le mcanisme dordonnancement partage de bande passante bas sur les

niveaux de priorit. Dune part, cette notion peut tre exploite pour distribuer quitablement les

ressources rseau indpendamment du comportement des sources. Dautre part, la notion des

coefficients de pondration attribus aux files dattentes peut rduire considrablement leffet de

pertes sur la transmission de flux multimdia.

Les travaux de ce projet se concentrent sur la dfinition, simulation et mise en oeuvre de

mcanismes dattribution de priorits et de gestion des ressources pour le modle DiffServ. Nous

proposons, ensuite, un modle analytique permettant lintroduction du rgulateur PID assurant

lajustement dynamique des priorits des files dattentes de DiffServ. Enfin, nous validons les

rsultats de limplmentation de lapproche de rgulation avec Network Simulator.

Mots-cls : Qualit de Service, DiffServ, WFQ, rgulateur PID, modlisation, simulation.


5/84

M. Hana - PFE - IRES L1

SommaireDEDICACE......................................................................................................................................i

AVANT PROPOS ......................................................................................................................... ii

RESUME....................................................................................................................................... iiiLISTE DES FIGURES................................................................................................................ L4

LISTE DES TABLEAUX ........................................................................................................... L6

LISTE DES ABREVIATIONS .................................................................................................. L7

INTRODUCTION GENERALE ..................................................................................................1

CHAPITRE I : LA DIFFERENCIATION DE SERVICES DANS LES RESEAUX ..............3

I- Introduction.................................................................................................................... 3

II- La qualit de service dans la conception des rseaux ............................................... 3II-1- Les paramtres de la qualit de service...................................................................4

II-1-1- Disponibilit .........................................................................................................4

II-1-2- Bande passante .....................................................................................................5

II-1-3- Latence (Delay) ....................................................................................................5

II-1-4- Variation des dlais de traverse (gigue ou jitter) ................................................6

II-1-5- Taux de pertes.......................................................................................................7

III- La rservation de ressources...................................................................................... 9III-1- Le modle IntServ....................................................................................................9

III-2- La solution MPLS ..................................................................................................10

IV- Le modle DiffServ.................................................................................................... 10

IV-1- Caractristiques du modle...................................................................................11

IV-2- Architecture de DiffServ........................................................................................12

IV-2-1- Agrgation de flux ............................................................................................14


6/84


IV-2-2-Traitement par noeud ( Per Hop Behavior ).......................................................15

IV-3- Le Traitement diffrenci de paquet dans le routeur DiffServ..........................15

IV-3-1- La classification de trafic ..................................................................................17

IV-3-2- Le conditionnement de trafic ............................................................................19

IV-3-3- Lordonnancement de trafic..............................................................................23

V- Intgration avec dautres services............................................................................. 24

V-1- Intgration IntServ/DiffServ...................................................................................24

V-2- Intgration MPLS/DiffServ ....................................................................................25

VI- Conclusion.................................................................................................................. 26

CHAPITRE II : EVALUATION DES PERFORMANCES DE DIFFSERV .........................27

I- Introduction.................................................................................................................. 27

II- Prsentation................................................................................................................. 27

II-1- Implmentation de Diffserv dans NS.....................................................................27

III- Lapport de lordonnanceur WFQ pour DiffServ................................................. 30

III-1- La discipline Fair Queuing....................................................................................30

III-2- La discipline Weighted Fair Queuing ..................................................................31

III-2-1- La discipline de service fluide GPS ..................................................................31

III-2-2- La discipline de service PGPS ou WFQ............................................................33

III-2-3- WFQ et la garantie de dlai pour un trafic (, ) born ....................................33

IV- Rsultats et Interprtations...................................................................................... 35

IV-1- Lquit de la bande passante ...............................................................................35

IV-2- Le taux de perte......................................................................................................38

IV-3- La borne sur le dlai ..............................................................................................40

V- La rgulation ............................................................................................................... 41

V-1- Besoin de la rgulation ............................................................................................41

V-2- La loi de commande.................................................................................................42

V-2-1- La loi de commande proportionnelle..................................................................42

V-2-2- La loi de commande intgrale ............................................................................43

V-2-3- La loi de commande drive ..............................................................................44

V-3- Le rgulateur PID....................................................................................................44


7/84


VI- Conclusion.................................................................................................................. 45

CHAPITRE III : MODELISATION ET IMPLEMENTATION DE LAPPROCHE DE

REGULATION DANS LE MODELE DIFFSERV...................................................................46

I- Introduction.................................................................................................................. 46

II- Aperu de lapproche de rgulation dans le modle DiffServ................................ 46

III- Intgration de rgulateur PID dans le modle DiffServ........................................ 47

III-1-Modlisation de la bande passante........................................................................48

III-2- Modlisation du dlai.............................................................................................49

IV- Evaluation des performances de la rgulation....................................................... 50IV-1- Description du scnario choisi...............................................................................51

IV-2- Module de rgulation de la bande passante.........................................................52

IV-2-1-Principe de fonctionnement de rgulateur de la bande passante........................52

IV-2-2- Interprtation des rsultats ................................................................................53

IV-3- La rgulation du dlai............................................................................................57

IV-3-1- Principe de fonctionnement de rgulateur du dlai...........................................57

IV-3-2-Interprtation des rsultats .................................................................................58

IV-4- Compromis entre le dlai et la bande passante rserve ....................................61

IV-4-1- Principe et Algorithme......................................................................................62

IV-4-2- Interprtation des rsultats ................................................................................63

V- Conclusion ................................................................................................................... 66

CONCLUSION GENERALE .....................................................................................................67

BIBLIOGRAPHIE.......................................................................................................................69


8/84


Liste des figuresFig I-1 : Dlai dans un rseau commutation des paquets ..............................................................5

Fig I-2 : Distribution de dlai et illustration de la gigue ..................................................................6

Fig I-3 : Architecture du modle DiffServ......................................................................................13

Fig I-4 : Le champ DSCP...............................................................................................................14

Fig I-5 : Les Composants QoS d'un routeur IP DiffServ ...............................................................16

Fig I-6: La fonction de classification .............................................................................................19

Fig I-7 : Le principe de la vrification ...........................................................................................20

Fig I-8 : Les mcanismes de rgulation de trafic : le seau perc et le seau jetons ......................22

Fig I-9 : La fonction de marquage..................................................................................................22

Fig I-10 : Classification de lordonnancement...............................................................................23

Fig II-1 : Configuration des files RED dans DiffServ ...................................................................28Fig II-2 : Topologie de la simulation .............................................................................................29

Fig II-3 : La discipline de service Round Robin ............................................................................31

Fig II-4 : La discipline de service GPS..........................................................................................32

Fig II-5 : Dlai maximal garanti par WFQ.....................................................................................34

Fig II-6 : Extrait de Policy Table et Policer Table .............................................................35

Fig II-7 : Les statiques de traitement des paquets .........................................................................35

Fig II-8 : Partage de la bande passante (1).....................................................................................36Fig II-9 : Partage de la bande passante ( Trafic On/Off)................................................................37

Fig II-10 : Leffet de lordonnanceur WFQ ...................................................................................38

Fig II-11 : Variation de taux de pertes ...........................................................................................39

Fig II-12 : Variation de dlai de bout en bout................................................................................40

Fig II-13 : Le principe de rgulation en boucle ferm ...................................................................41

Fig II-14 : Prsentation de lerreur.................................................................................................42

Fig II-15 : Effet de la commande proportionnelle..........................................................................43


9/84


Fig III-1 Principe dajustement des coefficients ...........................................................................46

Fig III-2 : Scnario de simulation ..................................................................................................51

Fig III-3 : Organigramme du module de rgulation de la bande passante .....................................53

Fig III-4 : Rsultat de rgulation de la bande passante ..................................................................54

Fig III-5 : Prsentation des rsultats de lapproche de rgulation de la bande passante................54

Fig III-6 : Rsultat de la simulation concernant lajustement des poids ........................................56

Fig III-7 : Rsultat de la simulation avec NS.................................................................................56

Fig III-8 : Organigramme du module de rgulation de la borne sur le dlai..................................58

Fig III-9 : Rsultat de lapproche de rgulation du dlai ...............................................................59

Fig III-10 : Variation de la valeur consigne et mesure.................................................................59Fig III-11 : Variation des priorits pour les flux vido et de donnes ...........................................60

Fig III-12 : Rsultat de la simulation avec NS (1) .........................................................................60

Fig III-13 : Rsultat de la simulation avec NS (2) ......................................................................61

Fig III-14 : Organigramme du module de rgulation du dlai et de la bande passante..................63

Fig III-15 : Rsultat de lapproche de rgulation (dlai et bande passante)...................................64

Fig III-16 : Rgulation du dlai maximal et de la bande passante.................................................64

Fig III-17 : Rsultat de la simulation avec NS (Bande passante)..................................................65

Fig III-18 : Rsultat de la simulation avec NS (le dlai maximal )...............................................66


10/84


Liste des tableaux

Tableau I-1 : Les besoins en qualit de service de certaines applications .......................................7

Tableau I-2 : Tableau comparatif des approches de QoS...............................................................12

Tableau I-3: La valeur du champ DSCP pour les diffrentes classes AF ......................................18

Tableau I-4: Tableau comparatif entre MPLS et DiffServ.............................................................25

Tableau II-1: Caractristiques des flux ..........................................................................................30

Tableau II-2: Taux de pertes pour le flux vido et de donnes......................................................39

Tableau III-1 : Paramtres de simulation .......................................................................................51

Tableau III-2 : Ajustement des pondrations des files...................................................................55

Tableau III-3 : Paramtres de la simulation ...................................................................................57

Tableau III-4 : Rsultats gnrs par le module de rgulation.......................................................65


11/84


Liste des abrviations

AF Assured Forwarding

BA Behavior Aggregate

BE Best Effort

CBR Constant Bit Rate

CBS Committed Burst Size

CIR Committed Information Rate

CP Code Point

CS Class Selector

DiffServ Differentiated Services

DSCP DiffServ Code Point

EDF Earliest Deadline First

EF Expedited Forwarding

FTP File Transfer Protocol

IETF Internet Engineering Task Force

IntServ Integrated Service

IP Internet Protocol

MF Multi Field

MPLS Multi Protocol Label Switching

NS Network Simulator

PID Proportionnel Intgral Driv

PHB Per Hob Behavior

RSVP Ressource Reservation Protocol

QoS Quality of Service

RED Random Early Discard


12/84


SLA Service Level Agreement

TCA Traffic Condition Agreement

TOS Type of Service

UDP User Datagram Protocol

WFQ Weight Fair Queuing


13/84

M. Hana - PFE - IRES 1

Introduction GnraleLa qualit de service ou QoS (Quality of service) est un nouveau concept incontournable

dans le monde des rseaux des tlcommunications. Bien que complexe, il na rien de

rvolutionnaire, puisquil se fonde sur des technologies prexistantes, quil vise rationaliser, et

souvent simplifier, afin den faciliter la mise en uvre. Nanmoins, la normalisation nest pas

encore acheve et de nombreuses philosophies saffrontent, avec un principal enjeu le

leadership de tel ou tel constructeur. Ce concept revt de multiples aspects technologiques, et

qui doit tre prcis selon ses objectifs et son contexte dutilisation.

En fait, la plupart des rseaux informatiques et tlcommunications reposent aujourdhuisur le protocole IP, conu lorigine pour vhiculer des donnes informatiques. Cependant, avec

la prolifration du rseau Internet marque par la croissance exponentielle du trafic et la

naissance de nouvelles applications, ce rseau se trouve face des problmes svres. Le best

effort nest plus suffisant pour suivre lvolution des technologies. Donc, il ne s'avre pas un

support de communication qui permet de satisfaire pleinement les contraintes varies de ces

nouvelles applications.

Face cette impasse, un effort de recherche important a t men, ces dernires annes,

pour quInternet offre un support d'interconnexion o de nombreux types d'applications puissent

cohabiter et fonctionner raisonnablement. Des solutions ont merg : celles requrant une

nouvelle architecture appele avec tat tels que larchitecture IntServ et celles maintenant la

proprit sans tat comme DiffServ.

Le traitement diffrenci de paquets est un concept relativement ancien dans lInternet. Il

est prsent ds lorigine du protocole IPv4 avec le champ ToS, mais une dfinition trop vague a

limit son dploiement. Ce concept a t redfini pour offrir un traitement adapt aux besoins trs


14/84

Introduction gnrale


htrognes des applications. En effet, le modle de diffrenciation de service (DiffServ) fournit

un cadre gnrique aux applications rseaux pour garantir un traitement par classe de service.

Cest dans ce cadre que nous situons notre projet de fin dtude intitul Etude des

mcanismes de diffrenciation de service . Il a pour vocation dexpliquer les mcanismes de

gestion de la qualit de service associs aux protocoles IP, particulirement le Differentiated

Services (DiffServ) et la possibilit dintgration de lapproche de rgulation dynamique aux

priorits des services de ce modle.

Ce rapport se compose de trois chapitres. Dans le premier, nous nous intressons la

prsentation gnrale des concepts de la qualit de service, ltude des principales

caractristiques de DiffServ et lexplication des mcanismes permettant cette architecturedassurer un traitement diffrenci des services tout en garantissant la qualit de service (Qos) de

bout en bout.

Dans le deuxime chapitre, nous valuons les performances dun tel modle par

simulation avec Network Simulator et nous tudions une solution permettant damliorer encore

plus le niveau de QoS. Nous dfinissons, en premire partie, la topologie mise en uvre lors de

lvaluation de DiffServ ainsi que des mesures pour certaines mtriques de QoS. La deuxime

partie est consacre la dfinition du concept de la rgulation PID ainsi que ses caractristiques

qui peuvent tre intgres pour lajustement dynamique des priorits pour les diffrents agrgats

de DiffServ.

Limplmentation et le test de lapproche de rgulation dans DiffServ sont prsents dans

le troisime chapitre. Nous commenons, dabord, par introduire les spcifications de notre

application, ensuite nous prsentons notre modle de rgulation pour certains paramtres de QoS

et enfin, nous dcrivons le prototype de test et les paramtres rguler.


15/84


Chapitre I

La diffrenciation de services dans les rseaux

I- Introduction

Internet a fonctionn sans que les usagers ressentent la ncessit d'introduire de traitement

diffrenci au niveau de la couche rseau. Le type de communication dominant le rseau, depuis,

est le transfert de fichiers et le web. Cependant, aujourdhui, on constate le dveloppement

d'applications s'appuyant sur des modes de communication la smantique radicalement

diffrente du transfert de fichier, comme la voix sur IP ou des applications interactives. Do le

service best-effort devient, alors, un support de communication peu satisfaisant pour ces types de

flux. En effet, il est peu difficile de supporter ces applications au niveau des protocoles de

transport seulement. Mais il est pertinent d'aller vers l'enrichissement de la couche rseau avec de

nouveaux mcanismes dordonnancement et de gestion de file dattente assurant une bonne

qualit de service.

Dans ce Chapitre, nous nous intressons une des mcanismes supportant ces

communications la smantique nouvelle, qui est le modle DiffServ. Tout dabord, nous

prsentons les indicateurs de service et les mcanismes retenus pour caractriser les performances

dun rseau et assurer une bonne qualit. Puis, nous dcrivons lapport du modle DiffServ.Ensuite, nous tudions les diffrents blocs fonctionnels dans le routeur de ce modle. Enfin nous

traitons la possibilit dintgration de DiffServ avec dautres modles.

II- La qualit de service dans la conception des rseaux

ses dbuts, Internet avait pour seul objectif de transmettre les paquets leurs

destinations. Conu pour le transport des donnes, IP (Internet Protocol) n'a pas t prvu


16/84



pour les applications en temps rel. Le besoin en quipements de plus en plus fiables, d'un bout

l'autre du rseau, est donc devenu incontournable. Cependant, les inconvnients rencontrs dans

les rseaux (perte de paquets, congestion) ne peuvent pas tre surmonts sans une rnovation

profonde de l'architecture.

La QoS dune application est dfinie comme tant lensemble des exigences requises par

cette application en terme de bande passante, dlai, gigue et taux de perte. Ces exigences sont

intrinsques la nature des applications. Ces dernires peuvent tre classes en deux catgories :

Les applications temps-rel : Ce type dapplications dites temps-rel ont un besoin

ferme en terme de dlai et de faible variation de dlai (gigue). Cependant, elles peuventtolrer quelques pertes de paquets.

Les applications non-temps-rel : Les applications dites non-temps-rel (ou Best-Effort)

sont plus sensibles aux pertes de paquets (par rejet) qu des dlais levs. Dans ce cas, la

fiabilit de la communication est plus importante que la garantie dun dlai born

Ainsi, on dfinit la qualit de service comme tant la mthode qui permet de garantir un

trafic de donnes, quelle que soit sa nature, les meilleures conditions d'acheminement rpondant

des exigences prdfinies. Elle fixe notamment des rgles de priorit entre les diffrents flux.

Dans la suite, nous nous focalisons sur les exigences requises par les applications en termes de

disponibilit, la bande passante, le dlai, la gigue et le taux de perte [1].

II-1- Les paramtres de la qualit de service

La matrise de la qualit de service est un enjeu essentiel. Elle doit tre visualise et

mesure de bout en bout. Le contexte joue un rle crucial dans lapprciation des paramtres de

la qualit de service quil faut adapter aux besoins de lentreprise.

II-1-1- Disponibilit

La disponibilit dun rseau se dfinit comme le rapport entre le temps de bon

fonctionnement du service et le temps total douverture du service. Cest la forme la plus

vidente de QoS, puisquelle rprsente la possibilit dutiliser le rseau [2].


17/84



II-1-2- Bande passante

La bande passante (ou le dbit maximum) est considre comme tant le taux de transfert

maximum pouvant tre maintenu entre deux points terminaux. La QoS ne gnre pas la bande

passante. En revanche, ses mcanismes permettent de grer de faon optimale la bande passante

du rseau en fonction des demandes des applications. Dans les rseaux commutation de

paquets, la garantie de bande passante est un paramtre de performance trs important pour

garantir la QoS aux flux temps-rel. Ces derniers, ont une exigence minimale en terme de bande

passante gale leur dbit moyen.

II-1-3- Latence (Delay)

La latence correspond au temps que require un paquet pour traverser le rseau dun point

dentre un point de sortie. Elle est gnralement appele le dlai de bout-en-bout. Ce

paramtre est introduit par les dispositifs intermdiaires du rseau tels que les routeurs ou les

commutateurs dans les rseaux commutation de paquets. La figure I-1 montre les diffrentes

composantes susceptibles dintroduire un dlai dans la transmission des paquets traversant le

rseau.

Fig I-1 : Dlai dans un rseau commutation des paquets

En gnral, la majeure partie du dlai est celle introduite par les files dattente en sortie.

En effet, plusieurs flux en entre se trouvent en concurrence pour accder au mdium de

transmission. Les algorithmes dordonnancement ont t mis en oeuvre pour assurer un partage

adquat des ressources en fonction des exigences des applications afin damliorer leurs

performances. Lexigence dune application en terme de dlai pourrait tre stricte, auquel cas le

Fonction de

routage ou

de

commutation

Dlai dattente

en entre

Dlai de commutation

ou de routage

Dlai dattente

en sortieDlai de

propagation

Dlai introduit par un dispositif

intermdiaire du rseau


18/84



rseau doit garantir une borne maximale sur le dlai instantan de bout-en-bout, ou moyen auquel

cas le rseau offre une valeur moyenne du dlai long terme avec la possibilit de fluctuations en

cas de surcharge du rseau.

II-1-4- Variation des dlais de traverse (gigue ou jitter)

La gigue se dfinit comme la variation des dlais dacheminement (latence) des paquets

sur le rseau. Ce paramtre est particulirement sensible pour les applications multimdias qui

requirent un dlai inter paquet relativement stable. Il dpend principalement du type et du

volume de trafic sur le rseau et du type et du nombre dquipements rseau. La figure I-2 montre

une distribution typique du dlai et illustre le concept de la gigue.

Fig I-2 : Distribution de dlai et illustration de la gigue

Les flux temps-rel tels que les flux vido, audio et voix sur IP sont trs sensibles la

gigue. En effet, la non considration de cette mtrique implique une discontinuit au niveau de la

restitution des donnes la destination. Par exemple, la variation de dlai dans une transmission

vido pourrait entraner des images saccades alatoirement ce qui dgrade considrablement la

qualit de service de lapplication. Pour rduire leffet de la gigue, les paquets temps-rel sont

buffriss la destination avant leur lecture. Pour cela, la gigue doit tre borne pour prvoir la

taille du tampon qui dpend principalement de la valeur de la gigue et du dbit de rception des

donnes [2].

Distr ibut ion

d u d l a i

d l a i

D l a i

m inD l a i

m ax

D l a i

m oye n

G igu e


19/84



II-1-5- Taux de pertes

Ce paramtre reprsente le pourcentage des units de donnes qui ne peuvent pas atteindre

leur destination dans un intervalle de temps spcifique. Cette perte peut tre le rsultat dun rejet

de paquets lorsque les ressources sont satures ou dun dpassement dchance. Dans une

application temps-rel, un paquet arrivant au-del de son chance ne fournira aucune

information utile lapplication. Le taux de perte est communment reprsent par la

probabilit de perte. La retransmission dun paquet perdu ne change pas la valeur de la

probabilit de perte mais fournit un moyen de recouvrement de perte [1].

La Qualit de Service peut tre rsume, donc, comme tant un traitement prfrentielpour certains types de trafic moyennant autant des paramtres qui la dcrit. Par exemple, la

variation de dlai est un facteur important pour les applications temps-rel (comme la Voix sur

IP). En effet, le trafic VoIP (voix sur IP) na pas besoin de beaucoup de bande passante mais il

ncessite un dlai et une gigue faible. Au contraire, le trafic FTP (File Transfert Protocol)

ncessite une largeur de bande importante mais le dlai nest pas un critre primordial. Le tableau

ci-dessous rsume les besoins en qualit de service de certaines applications susceptibles d'tre

transports sur les rseaux haut dbit [3].

ServiceDbit moyen

(Mbit/s)

Dlai

maximum (s)

Gigue maximum

(ms)

Taux derreur

par bit

Taux derreur par

message

Voix non

compresse0.064 0.25 10 < 10 -1 < 10 -1

Vido

compresse1 30 0.25 1 < 10 -6 10 -9

Image 1 10 1 - 0 10 -4 0 10 -9

Transfert de

fichiers1 100 1 - 0 0

Tableau I-1 : Les besoins en qualit de service de certaines applications

Le problme lheure actuelle est que la plupart des rseaux ont un ou plusieurs liaisons

critiques qui dgradent les performances des applications. Ceci vient du fait quil ny a pas de

distinction entre le trafic prioritaire et le trafic non prioritaire. La solution propose par la

diffrenciation des services est de sparer les deux types de trafic sur les liens critiques. Donc,


20/84



dans le cas o le rseau serait satur, une alternative laugmentation de la bande passante est la

diffrenciation du trafic. Actuellement, il y a deux modles, proposs par lIETF, permettant la

diffrenciation du trafic tels que IntServ et DiffServ.

II-2- Les principaux mcanismes de gestion de QoS

Pour satisfaire les besoins des applications dans les rseaux commutation de paquets,

une premire solution suggre dallouer plus de bande passante aux flux, afin de rsoudre les

problmes de congestion, perte de paquets et de dlai puisque la bande passante devient

disponible faible cot. Cependant, plusieurs applications temps-rel ont besoin de garanties

particulirement en terme de dlai, gigue et taux de perte et non seulement en terme de bande

passante. La proposition dallouer des ressources supplmentaires nest pas un choix judicieux

pour assurer la QoS. Dune part, ce choix conduit un surdimensionnement du rseau rduisant

ainsi son taux dutilisation en temps normal. Dautre part, avec lmergence des applications

multimdia et lutilisation croissante des rseaux commutation de paquets tels que lInternet, la

saturation rapide de la totalit des ressources du rseau est prvue. Ceci ramne de nouveau la

situation de ressources limites. La deuxime solution consiste fournir les mcanismes

ncessaires pour assurer la QoS qui se rsument principalement en trois fonctionnalits

supplmentaires aux services fournis par le rseau. Cest un ensemble de traitements diffrencis

raliss soit au niveau de la source de trafic (terminal metteur) soit dans les organes du rseau.

On peut distinguer les mcanismes suivants [2]:

Le traffic shaping ou mise en forme du trafic consiste principalement introduire

du dlai entre les missions de paquets de manire viter ou limiter les rafales de

trafic.

Le traffic policing est une opration qui consiste vrifier que le trafic mis est

bien conforme la description qui a t faite par la source. Le mcanisme de buffer management ou gestion de buffer consiste liminer des

paquets en cas de congestion du buffer dune interface de sortie de manire slective,

en fonction des paramtres de QoS associs aux flux.

Lopration de traffic scheduling consiste ordonnancer la transmission des paquets

prsents dans les buffers de linterface de sortie en fonction des paramtres de QoS

associs aux flux. Cette opration peut tre effectue par diffrents algorithmes.


21/84



Le domaine de la qualit de service est trs vaste et complexe puisque les applications ne

cessent de se dvelopper et les exigences varient et se ramifient. Cest un thme dynamique qui

accrot avec le progrs technique. Nous avons prsent dans ce qui prcde la notion de QoS, ses

paramtres ainsi que les mcanismes permettant son contrle. Ces derniers ralisent des actions

ncessaires au support de la QoS dans le rseau. Le placement et la configuration de ces

mcanismes dans le rseau, ainsi que leurs interactions, dfinissent un "modle" de qualit de

service. Nous nous intressons dans la suite tudier le modle Diffserv permettant de dfinir

une configuration statique des mcanismes suite lidentification des besoins de QoS les plus

gnraux.

III- La rservation de ressources

Une solution idale du contrle de la performance de transmission des paquets est

d'ajouter au rseau un systme de rservation de ressources. Ainsi, l'metteur d'un flux est assur

d'obtenir la performance qu'il souhaite, que ce soit en terme de dbit, de dlai ou de taux de perte.

III-1- Le modle IntServ

Un systme puissant de rservation de ressources sur Internet est l'architecture Intserv

(Integrated Service), standardise par LIETF et destins dfinir une architecture Intgrationde Services. Dans un tel modle, il est possible de garantir le taux de perte et le dlai

dacheminement observs par un flux individuel, tout en contrlant la distribution de ressources

entre les flux. Le modle IntServ prsente les caractristiques suivantes [4]:

Il est orient rcepteur, ce qui permet la rservation de ressources pour les flux

multicast. En change, il a t ncessaire de dterminer un mcanisme pour

assurer des routes symtriques entre les metteurs et les rcepteurs.

Pour que la qualit de service puisse tre garantie, des ressources doivent tre

rserves dans chaque routeur. En consquences des fonctions de contrle daccs,

de classification et de gestion de ressources sont implantes dans chaque noeud du

rseau. Cette architecture introduit l'tablissement de circuits virtuels l'aide d'un

protocole de signalisation (RSVP) [5].

La granularit spcifie par le modle permet de rserver des ressources jusquau

niveau des microflux, en augmentant le nombre de rservations qui doit tre gr

par chaque routeur.


22/84



Cependant, le principe de simplicit au niveau rseau, est remis en cause puisque les

routeurs ont des tches dsormais complexes de gestion des flux, contrle de l'utilisationetc.

De plus, au niveau technique, la faiblesse principale de larchitecture IntServ est sa non-

rsistance au facteur dchelle [1]. Le nombre de flux qui peuvent bnficier dune rservation est

assez limit, en particulier dans les routeurs du coeur du rseau. Ces quipements doivent traiter

des milliers des flux simultanment, et le cot introduit par la gestion dtats et lordonnancement

par flux peut entraner une rduction considrable de leurs performances.

La standardisation du modle IntServ sest pratiquement acheve en 1996. Pourtant, le

modle na jamais t implant grande chelle dans le rseau. Les faiblesses numres

prcdemment empchent son dploiement. De nouvelles propositions cherchant offrir desgaranties strictes dans le rseau sont actuellement ltude. Elles se basent sur une architecture

hybride IntServ-DiffServ.

III-2- La solution MPLS

Une solution qui connat un certain succs auprs des oprateurs, aujourd'hui, est le

protocole MPLS. Cest un standard de rservation de circuits virtuels que devrait fonctionner sur

la plupart des quipements de niveau liaison (sans passer par IP et les tables de routage) [1]. Bien

que la rservation de circuits soit performante, elle n'est pour l'instant possible qu' l'chelle d'un

domaine administratif et pour un nombre relativement faible de circuits. La gnralisation de

MPLS et l'interconnexion de domaines MPLS sont des thmes actifs aujourd'hui, qui offriront

certainement terme, des solutions d'ingnierie de trafic.

L'impasse de la rservation de ressource grande chelle a conduit l'IETF travailler sur

une seconde architecture appele DiffServ. Elle s'appuie sur la notion de priorit entre les paquets

et non sur la rservation de ressources dans les routeurs.

IV- Le modle DiffServ

Les crateurs de lIntServ observent plus attentivement les dfauts de cette architecture et

cherchent faire des modifications pour assurer sa prennit. Pendant la mme priode, des

nouvelles propositions dcrivent des mcanismes plus simples capables de satisfaire les besoins

de QoS dun grand nombre dapplications. Ces propositions ont servi de base la dfinition du

modle DiffServ. Le groupe de travail de Diffserv sest centr sur la dfinition dun modle


23/84



simple, modulaire, dont la mise en oeuvre peut seffectuer dune manire graduelle dans

lInternet existant.

IV-1- Caractristiques du modle

Les modles DiffServ et IntServ cherchent rsoudre les mmes problmes tels que le

traitement correct des flux multimdia et un meilleur contrle dans la distribution de la bande

passante. Nanmoins, le modle DiffServ sattaque ces contraintes d'une manire moins

ambitieuse mais plus rsistante. Dans ce modle, il est impossible doffrir des garanties strictes

ou de rserver des ressources. Par contre, la simplicit d'implantation permet cette nouvelle

architecture de se voir dploye progressivement dans certaines rgions de l'Internet [8].

Une des faiblesses du modle IntServ est sa non-rsistance au facteur dchelle

(volutivit). Dans ce dernier, tous les quipements du rseau doivent garder un tat par flux

rserv. Il suffit quun nud dans la route nimplmente pas les fonctionnalits IntServ pour que

la QoS ne puisse plus tre strictement garantie. Cependant, dans larchitecture DiffServ, la

priorit est donne au regroupement des flux dont les besoins sont similaires (agrgation) et la

dfinition des traitements ncessaires dans les routeurs pour que l'agrgat de ces flux soit trait

correctement.

Pour assurer la robustesse du modle, la cration d'tats et la classification par flux sont

deux fonctionnalits rserves aux routeurs dentre au rseau. Dans ces quipements, le nombre

de flux traiter est considrablement rduit. Dans le reste des routeurs, des oprations trs

simples, ne demandant pas la cration dtats, assurent le traitement diffrenci.

Une autre reproche faite au modle IntServ est la complexit du protocole de signalisation

RSVP [1]. Une grande partie de la lourdeur du protocole est due la gestion des flux multicast et

des routes symtriques. La rservation de ressources pour des flux exige la dfinition de rgles

dagrgation et dsagrgation dans les noeuds intermdiaires. Dans DiffServ, ce problme na past spcifiquement abord car les connexions multi-point ninterfrent pas avec les mcanismes

propres larchitecture. Dans ce modle, la seule signalisation requise est une tiquette contenue

dans len-tte de chaque paquet. Nous rsumons dans le tableau ci dessous, les diffrences entre

ces deux approches :


24/84



IntServ DiffServ

Type de diffrenciation garantie absolue garantie statistique

Granularit de

diffrenciationmicro - flux Agrgats

Etats Par flux Par agrgat

Base de classification Plusieurs champs dentte Un champ : DS

Signalisation Explicite Implicite dans le coeur

Rservation requise (RSVP) Non requise dans le coeur

Types routeurs Un type Deux types : bordure/cur

Extensibilit Limite par nombre de flux Limite par nombre declasses

Tableau I-2 : Tableau comparatif des approches de QoS

IV-2- Architecture de DiffServ

Lide consiste diviser le rseau en domaines. Ainsi, on distingue lintrieur dun

domaine des routeurs daccs (Core router) et dautres de bordure (Edge router). Les routeurs

daccs sont connects aux clients, tandis quun routeur de bordure est connect un autre

routeur de bordure appartenant un domaine diffrent. Le modle DiffServ est bas sur une

architecture qui permet des prises de dcision complexe aux bords et donc moins de charge sur

les routeurs du backbone. En effet, les routeurs dextrmits sont chargs de conditionner le trafic

entrant en indiquant explicitement sur le paquet le service quil doit subir. Ils examinent les

paquets, les classifient selon une politique spcifie par ladministrateur de rseau, les marquent

et excutent des fonctions de profilage. Ainsi, la complexit des routeurs ne dpend plus du

nombre de flux qui passent mais du nombre de classes de service. Ces dernires sont identifiespar une valeur code dans l'en-tte IP [8].

La figure ci dessous montre un exemple de configuration de rseau. Un site metteur,

souhaite que ses flux bnficient dun traitement diffrenci dans le rseau. Il tablit un contrat

de service avec son fournisseur. Ce contrat, appel SLA (Service Level Agreement), contient la

nature du trafic que lmetteur peut produire pour chaque service demand. Dun cot, le


25/84



fournisseur sengage fournir la qualit demande par lmetteur. De son cot, lmetteur est

conscient des limitations imposes par le contrat.

Fig I-3 : Architecture du modle DiffServ

Le client peut effectuer un pr-marquage de ses flux avant de les transmettre au

fournisseur. Signaler une prfrence en termes de classe de service ou indiquer limportance

relative des paquets sont deux raisons qui justifient cette action. La priorit des paquets peut

varier au sein dun flux. Par contre, les principes de DiffServ exigent que tous les paquets dun

mme flux appartiennent une mme classe de service afin dviter le dsquencement.Le fournisseur connat les spcifications techniques du contrat tabli avec chacun de ses

clients. Quand le trafic produit par lutilisateur arrive au routeur dentre du fournisseur, les flux

sont identifis et leur comportement est vrifi en fonction du contrat respectif. En cas de non-

conformit, une action corrective est prise. Pour certains services, seuls les paquets conformes au

contrat peuvent entrer dans le rseau. Pour dautres services, tous les paquets sont accepts, mais

le routeur dentre modifie la priorit du paquet en fonction du niveau de conformit. En quittant

le routeur dentre, les paquets du site metteur contiennent tous une tiquette refltant la classe

de service souhaite et le niveau de conformit du flux par rapport au contrat.

Les routeurs du coeur du rseau ne modifient pas les tiquettes. Ils se contentent de les

utiliser pour choisir la file dattente o le paquet est insr. Pour cet exemple, la file dattente

reprsente la classe de service. Les ressources des routeurs sont distribues entre les files en

fonction des services quils supportent. Dans chaque file dattente, un algorithme de rejet slectif

est utilis pour liminer, en premier, les paquets de basse priorit en cas de congestion [9].

ISPISP

Backbone (routeurs du coeur)

routeur de

frontire

metteur


26/84


27/84



En effet, les trois premiers bits de DSCP sont appels Class Selector. Les codes DSCP de

type xxx000 (ou x est une variable binaire) correspondent aux classes de services principales.

Ceux-ci seront associs aux PHB (Per Hop Behviour) qui permettront le traitement diffrenci

des flux dans les routeurs intermdiaires. Plus la valeur de code point est leve, plus le flux

correspondant sera prioritaire. Les deux derniers bits sont inutiliss [7].

Les agrgats sont en nombre rduit, fix, bien infrieur au nombre de flux distincts qui

peuvent traverser un routeur. C'est le petit nombre de classes qui permet aux routeurs de coeur de

mettre en oeuvre un traitement diffrenci moins coteux que celui des routeurs IntServ. Le

modle DiffServ spare le trafic par classes. Nous avons donc affaire une granularit moins fine

mais qui devient en revanche plus volutive. En effet, la granularit du flot implique la ractionen chane suivante : plus il y a d'utilisateurs dans le rseau, plus il y a de flots ainsi que des

variables de classification et d'ordonnancement dans les routeurs maintenir. Ceci a pour

consquence une charge importante au niveau des routeurs qui deviennent alors de moins en

moins performants.

IV-2-2-Traitement par noeud ( Per Hop Behavior )

L'architecture consiste aussi en un ensemble de mcanismes simples au niveau de coeur

de rseau, agissant sur un nombre rduit de classes de service, dont la smantique est dfinie nonpas de bout en bout mais par routeur (per-hop behavior). Les PHBs sont les mcanismes mis en

oeuvre dans le coeur de rseau, ceux qui pratiquent le traitement diffrenci entre les classes. Ils

sont dfinis par les constructeurs dans les routeurs en utilisant des mcanismes de gestion de files

d'attente (Round Robin, Weighted Fair Queuing,...) et de rgulation de flux. En effet, deux

modles ont t standardiss par lIETF tels que PHB Expedited Forwarding (EF) et PHB

Assured Forwarding (AF).

IV-3- Le Traitement diffrenci de paquet dans le routeur DiffServ

Le routeur DiffServ agrge le flux en un ensemble de Behaviour Aggregate qui seront

achemins de la mme manire, ce qui assure une simplification des traitements et de stockage

dans le routeur. Ainsi, larchitecture DiffServ dfinit quatre types dlments qui constituent le

chemin emprunt par les flux lorsquils passent par le routeur. Ces composants sont le

classificateur de trafic, les lments dactions, de mesures et les gestionnaires de file dattente. La

tche du classificateur de trafic est de slectionner les flux correspondants des critres comme


28/84


29/84



est indpendante des dtails des offres de service et peut stendre du simple marquage aux

oprations complexes de lissage et policing . Les routeurs l'intrieur d'un domaine, quant

eux, se consacrent exclusivement au traitement des paquets en utilisant le marquage spcifi par

les nuds de bord.

IV-3-1- La classification de trafic

Le classificateur au niveau de routeur DiffServ traite un flux en entre et gnre N flux en

sortie spars logiquement. La sparation en des classes de flux est ralise par des filtres. En

effet, il sagit de choisir des paquets dans un flot de trafic bas sur le contenu dune certaine

partie de lentte du paquet. Gnralement, on distingue deux types de classificateur. Le premier,

appel BA (Agrgat de comportement), utilise comme cl de classification le code point et le

deuxime, appel MF (Multi Field), slectionne les paquets en se basant sur la valeur dune

combinaison dune ou plusieurs zones dentte, telles que ladresse source, ladresse destination,

le champ DS, lidentification du protocole, les numros de port source et destinationetc. Ainsi,

le filtre consiste un ensemble de conditions sur les valeurs composantes les cls de la

classification du paquet [12].

Dans larchitecture DiffServ, lors dune arrive de flot non classifi au niveau de Edge

Router , les filtres sont utiliss pour slectionner les paquets IP en fonction des informationscontenues dans lentte IP. Une fois les paquets sont filtrs, ils sont mis dans des classes

indpendantes et peuvent tre contrls dune manire indpendante. Chaque agrgat possde son

propre gestionnaire de file dattente. Ainsi, le routeur arrive faire du traitement diffrenci. Le

modle DiffServ introduit trois PHB ou classes de services dfinies comme suit :

1. Expedited Forwarding (EF) ou Premium Service (RFC 2598) : cette classe correspond

la valeur 101110 de DSCP. Son objectif est de fournir un service de transfert

quivalent une ligne virtuelle ddie travers le rseau dun oprateur. Les paquets

excdentaires sont lisss ou rejets lentre pour toujours rester conforme au contrat

SLA. De plus, les flux ne doivent avoir que trs peu de perte, la gigue doit tre

minimale et la bande passante garantie. On utilise couramment cette classe pour le

transport de donnes temps rel tel que la voix ou la visioconfrence [11].

2. Assured Forwarding (AF) (RFC 2597) : Il s'agit du second modle de service

standardis par l'IETF qui reprsente N classes de services et M niveaux de taux de

perte dans chaque classe. Il regroupe plusieurs PHB garantissant un acheminement de


30/84


31/84


32/84



Fig I-7 : Le principe de la vrification

B- le Shaper et le Dropper

Suite la vrification de la conformit vis--vis dun profil, le lissage peut seffectuer

lorsque les flux dune classe dpassent le contrat SLA prdfini. Cette fonctionnalit nest pas

systmatique et correspond une rgle de policing explicite dans le SLA. Les paquets sont

alors mis en file dattente afin dtre transmis un peu plus tard lorsque le dbit de la classe sera

considr comme tant dans le profil du contrat. Le rejet des paquets intervient pour garantir le

dbit fix pour chaque classe de service. Dans le cadre dun lissage, pour les files dattente ayant

une taille finie, des dpassements de profil trop importants peuvent aussi provoquer un rejet des

paquets. Ainsi le rgulateur de trafic assure principalement deux fonctions :

Mise en forme du trafic (Traffic Shaping) : implante gnralement auprs des sources de

trafic. Cette fonction permet de lisser le flux gnr lentre du rseau pour tre

conforme une spcification particulire. Elle permet de contraindre le trafic pour le

rendre conforme sa spcification connue par le rseau.

La surveillance du trafic (Traffic Policing) : Implante dans les dispositifs du rseau, cette

fonction permet de vrifier la conformit du trafic son contrat, c'est--dire sa

caractrisation dclare lors de sa ngociation avec le rseau en phase du contrle

dadmission [12].

La diffrence entre ces deux fonctions rside dans leurs actions vis--vis dun paquet non

conforme. Dans ce cas, la fonction de mise en forme du trafic retarde le paquet jusqu ce quil

soit conforme. Cependant, le traitement dun tel paquet dans la fonction de surveillance du trafic

dpend de la politique adopte. En effet, lors de larrive dun paquet non conforme, lalgorithme

C las s 1

C las s3

C las s2T ra f f i c D es c r i p to r (

V o lum e + t ra i t em en t )

M e t e r M a r k e r

D ro p p e r

F lu x E F n o n

c o n fo rm e

F lu x A F

F lux E F co n for m e

S LA


33/84



de surveillance de trafic peut dcider de retarder le paquet jusqu ce quil soit conforme, de

lliminer entirement ou de dcrmenter sa priorit avant de le transmettre. Les mcanismes de

rgulation de trafic permettent dimposer une forme spcifique au flux rgul. Thoriquement,

cette forme est exprime par une fonction quelconque qui limite le nombre cumulatif darrives

de paquets, appele courbe darrive, dans nimporte quel intervalle de temps. En pratique, cette

fonction est typiquement linaire pour des raisons de simplicit dimplmentation. Il existe deux

modles de courbes darrive linaires [2]:

Le modle de dbit crte permet de limiter le dbit maximal dune source de trafic un

dbit crte. Il est caractris par la taille de paquet maximal not Met le temps dinter-

arrive minimal entre deux paquets conscutifs nots Tmin. Ainsi, le dbit crtequautorise le rgulateur de trafic est P = M / Tmin.

Le modle dbit moyen permet de limiter le dbit moyen dune source de trafic. Ce

rgulateur est caractris par deux paramtres : la taille de la rafale permise note b et le

dbit moyen not r.

Ces formes de trafic linaires sont gnralement obtenues par des rgulateurs appels seau

jetons (Token Bucket) et seau perc (Leaky Bucket). Le rgulateur du seau jetons [13] dispose

dun seau de jetons de taille b qui sont gnrs au rythme constant de r jetons par seconde.

Chaque paquet qui arrive consomme un nombre de jetons proportionnel sa taille. Sil ny a pas

assez de jetons dans le seau, le paquet sera mis en attente dans la file jusqu avoir le nombre

ncessaire de jetons, sinon il sera transmis. Le rgulateur du seau perc dispose dun seau de

taille b initialement vide. A chaque arrive dun paquet le seau est rempli avec une quantit de

fluide gale la taille du paquet. Le seau perc est vid du fluide au rythme constant r. Si la

quantit de fluide ajoute lors de larrive fait dborder le seau, alors le paquet est rejet par le

rgulateur. Dans le cas contraire, le paquet est transmis vers le rseau. La figure suivante illustre

les deux mcanismes du seau jetons et du seau perc.


34/84



Fig I-8 : Les mcanismes de rgulation de trafic : le seau perc et le seau jetons

C- Le marqueur

Le marquage fait rfrence la mise jour de la valeur du champ DS dans len-tte IP. En

effet, les informations fournies en entre par le vrificateur et le classificateur permettront de

faire un choix sur la priorit appliquer chaque flux. Le bloc de marquage par exemple peut

dcider quen cas de dpassement du contrat, les flux excdentaires seront marqus avec une

priorit moindre. Les marqueurs placent dans la zone DS dun paquet un code point particulier decomportement DS. Donc, cest dans ce module que sera affect le champ DSCP. Ce traitement

est bas actuellement sur deux token buckets. Le principe se rsume comme suit [12] :

Si le trafic est conforme aux deux, les paquets sont marqus en vert,

Si le trafic nest conforme quun des deux, les paquets seront marqus en orang.

Si le trafic nest conforme aucun alors les paquets seront marqus en rouge et ils auront

une probabilit de rejet plus importante que les autres.

Fig I-9 : La fonction de marquage

DSCP class2

DSCP class2

DSCP class2DSCP Class1

Marker

r

b

Paquets

arrivs

Rgulateur du seau perc

rVers le rseau

b

Paquets

arrivs

Jetons

Rgulateur du seau jetons

r


35/84


36/84



passante, elle permet de partager dynamiquement des ressources en respectant le critre de la

bande passante. Lalgorithme EDF est lalgorithme le plus connu dans les rseaux industriels.

Dans les rseaux commutation de paquets, lordonnancement guid par le contrle de bande

passante est le plus utilis pour assurer un partage quitable des ressources. Nous retrouvons

principalement les algorithmes Round Robin, WFQ et toutes leurs variantes.

Le choix dun algorithme dordonnancement adquat a un impact trs important pour la

fourniture de la QoS des applications temps-rel. Dans les rseaux commutation de paquets, la

technique classique pour privilgier le service dune application sous contraintes temporelles, par

rapport une autre application moins contraignante, est de lui affecter une priorit plus leve et

dordonnancer les flux en concurrence daccs au mdium de transmission selon leurs priorits.Cest lordonnancement priorit fixe. Bien que cette technique reste efficace pour amliorer la

QoS temporelle des flux prioritaires, elle pourrait tre coteuse pour les flux moins prioritaires.

En effet, dans le cas o il nexisterait pas de mcanismes de contrle dadmission pour contrler

laccs de nouveau flux de priorits leves, le problme de famine serait invitable pour les flux

moins prioritaires dans le cas o les flux de priorit consommeraient la quasi-totalit des

ressources. En plus, un flux plus prioritaire malveillant pourrait affecter srieusement le dlai et

la gigue exerce par les autres flux moins prioritaires partageant les mmes ressources daccs au

mdium de transmission.

Pour viter ces problmes, la tendance actuelle de lordonnancement des applications

temps-rel dans les rseaux commutation de paquets consiste rserver les ressources

ncessaires en terme de bande passante par le biais des algorithmes partage de bande passante

Round Robin, WFQ. Ce dernier est dtaill dans le chapitre suivant.

V- Intgration avec dautres services

V-1- Intgration IntServ/DiffServ

Des travaux sont mens au sein de lIETF pour faire coexister les architectures IntServ et

DiffServ dans lInternet. Il semble assez naturel que lapproche IntServ soit utilise dans les

rseaux dentreprise ou les rseaux de petite taille, alors que DiffServ sera utilis pour les rseaux

de transit ou les coeurs de rseaux importants. Nous aboutissons, donc, vers un scnario o la

visibilit de lutilisateur est IntServ, alors que le systme de communication utilise DiffServ,

rendant ainsi IntServ client de DiffServ. Lintgration de ces deux mcanismes est en cours dtude.


37/84



Plusieurs propositions ont t soumises. La premire solution consiste raliser lintgration de

service que dans les sites terminaux. Le coeur du rseau ne traite pas les messages de signalisation

mais les transmet comme des paquets normaux qui sont nouveau interprts dans le site destinataire.Un contrle dadmission en bordure du rseau DiffServ permet de dterminer si le flux peut entrer

dans la classe de service. Lautre possibilit est de considrer le rseau DiffServ avec la classe EF

comme un lment de rseau et le caractriser pour permettre de construire un service garanti [1].

V-2- Intgration MPLS/DiffServ

MPLS permet de simplifier ladministration dun coeur de rseau en ajoutant de nouvelles

fonctionnalits particulirement intressantes pour la gestion de la qualit de service. Dans le

mme esprit que larchitecture DiffServ, MPLS permet de rduire le cot des traitements associs

au relayage des paquets en les reportant la priphrie du rseau. Il apporte aussi un mcanisme

de routage hirarchique efficace, cest--dire des tunnels permettant de grer les rseaux privs

virtuels. Le principe de MPLS est dattribuer un label chaque paquet lorsquil entre dans le

rseau. Ce mcanisme permet dviter le calcul complexe de routage classique et doter le monde

IP dun mode connect. Cette tiquette est attribue en fonction de la classe de service laquelle

appartient le paquet. La dfinition de ces classes dpend de loprateur du rseau mais elle peut

prendre aussi en compte la classe de service DiffServ. Ltiquette dcide donc dans chaqueprochain routeur, du comportement DiffServ et de lutilisation ventuelle des ressources

rserves. Ainsi la mise en correspondance va consister associer chaque classe Diffserv un

LSP-MPLS distinct dot de QoS quivalente. Ceci peut tre possible en utilisant le champ

exprimental de lentte MPLS pour stocker la valeur de Drop Precedence [6].

La solution MPLS Le modle Diffserv

Type de services Une connexion virtuelle (LSP) Service sans connexion

Routage Bas sur les labels. Routage classique (entte IP)

Rservation des

ressourcesProtocoles RSVP et CR-LDP Au niveau de DSCP

QoSPlusieurs contrats (plusieurs

labels)SLA tabli avec lmetteur

Tableau I-4: Tableau comparatif entre MPLS et DiffServ


38/84


39/84


40/84


41/84


42/84


43/84

Evaluation des performances de DiffServ


Fig II-3 : La discipline de service Round Robin

La discipline de service FQ nest pas destine servir des flux ayant des besoins

diffrents en terme de bande passante. Son objectif se limite fournir la mme portion de la

bande passante tous les flux. Aussi, la garantie quitable du mme taux de bande passante

tous les flux nest possible que lorsque tous les paquets aient la mme taille. En effet, les flux de

paquets de large taille auront plus de bande passante que les flux de taille de paquets plus petite.

De plus, cette discipline est sensible lordre darrive des paquets. En effet, si un paquet arrive

une file dattente vide immdiatement aprs avoir t visite par lordonnanceur, alors ce paquet

doit attendre la fin de service de tous les paquets des autres files dattente avant dtre transmis

[19].

III-2- La discipline Weighted Fair Queuing

Pour rsoudre les problmes du FQ, un service en tourniquet bit--bit a t propos. Cest

un modle thorique, pour le partage quitable de la bande passante. De plus, la notion du poids a

t introduite pour pondrer le service proportionnellement la bande passante exige par le flux.

Cette proposition est appele Weighted Fair Queueing (WFQ). Cette discipline de service est

connue aussi sous le nom de GPS (Generalized Processor Sharing) et PGPS qui est la version

paquet de GPS et qui correspond exactement WFQ dfinie par Parekh [16].

III-2-1- La discipline de service fluide GPS

La discipline de service GPS (Generalized Processor Sharing) est un modle thorique de

multiplexage de flux qui se charge de transmettre les paquets bit par bit en fonction de leurs

poids. La figure II-4 montre le droulement de la discipline de service GPS.

Classificateur Round

Robin


44/84



Fig II-4 : La discipline de service GPS

Plus formellement, un serveur GPS est caractris par les taux de service affects,

{ N1..... }, chacun des N flux actifs. Un flux est dit actif dans lintervalle de temps [t1, t2], si la

file dattente de ce flux est toujours pleine durant cet intervalle. Le serveur opre capacit fixe

C.

Notons par Wi (t1, t2) la quantit de service reue par le flux i dans lintervalle de

temps [t1, t2]. Le serveur GPS est dfini tel que :

(1)pour tous les flux actifs iayant des paquets en attente et sur tout intervalle [t1, t2]. Ainsi, en

faisant une somme sur j = 1N pour une valeur de i fixe, on obtient:

(2)

Par consquent, la bande passante garantie au iemeflux est :

(3)

Avec 1j1...Nj

==

. Ainsi, le flux actif reoit un service minimum gal ir tant quil a des paquets

en attente de service.

GPS est une discipline fluide non implantable en ralit qui suppose que le serveur peut

servir simultanment plusieurs flux. Dans un systme raliste qui considre des paquets, un seul

GPS

P11 P12 P13 P14

P21 P22

P31 P32

Flux1

Flux2

Flux3

P1= 0.5

P2= 0.25

P3= 0.25

Pij : j me paquet de i me flux

Pi = Taux de service du i me flux

( )( ) N1,2,...,j,t,tW t,tW ji

21j

21i =

( ) ( )21j

1...Nj

i21i t,tC

t,tW

=

C

r

j

1...Nj

i

i =

=


45/84



flux peut tre servi un instant donn et un paquet doit tre servi entirement avant quun autre

paquet puisse ltre. Il existe plusieurs techniques qui permettent dmuler la discipline GPS.

Lalgorithme WFQ (ou PGPS) est la version paquet la plus rpandue.

III-2-2- La discipline de service PGPS ou WFQ

Le systme WFQ est une mulation du systme GPS propos par Parekh et Gallager [16].

Ce serveur consiste servir les paquets dans lordre croissant de leurs instants de fin de service

dans le systme GPS correspondant. Ces instants sont appels date virtuelle de fin de service.

Le processus dordonnancement de WFQ consiste calculer la date virtuelle de fin de

service de chaque paquet pour muler le systme GPS. La date virtuelle de fin de service

correspond linstant de fin dmission dans le modle fluide. Linstant de dpart du serveur

GPS est dfini par [19] :

(4)

Avec :

- kiF : La date virtuelle de fin de service du keme paquet du ieme flux,

- ( )kitV : La date virtuelle darrive du keme paquet du ieme flux,

- kit : La date relle darrive du keme paquet du ieme flux,

- { ( ) }ki1ki tV,Fmax : reprsente la date virtuelle du dbut de service keme paquet.

Cette opration assure que le paquet ne commence pas son service avant que le paquet

prcdent du mme flux nait termin son service. La date virtuelle de fin de service kiF est

marque dans le paquet. Ensuite, le serveur WFQ ordonnance les paquets dans lordre croissant

de ces estampilles temporelles.

III-2-3- WFQ et la garantie de dlai pour un trafic (, ) born

Un flux temps-rel est gnralement reprsent par sa contrainte de rafale (, ) o

reprsente la taille maximale de rafale du flux et reprsente son dbit moyen. Un tel flux est dit

(, )-born et par consquent le nombre des paquets arrivs (ou bits) pendant la dure t est

borne par la fonction linaire +*t. Formellement, un flux ayant la fonction darrive

cumulative est dite (, )-born si et seulement si :

{ ( ) }i

kik

i1k

ik

iL

tV,FmaxF +=


46/84



(5)

La fonction darrive cumulative du flux ( )tR est alors limite par la courbe darrive

suprieure ( )st+ . Dans le formalisme du Network Calculus, la garantie de la bande passante

assure par WFQ se traduit par une courbe de service de la forme ( ) ( )TtRtT,R = o R est la

bande passante rserve et Treprsente la latence maximale du service. Cette courbe, prsente

dans la figure ci dessous, est appele courbe de service dbit-latence (Rate-Latency Service

Curve). Gnralement,C

Lmax dnote la latence introduite pour transmettre le paquet de plus grande

taille, o Lmaxreprsente la taille maximale du paquet parmi tous les paquets servis par WFQ et Ctant la capacit du serveur.

Fig II-5 : Dlai maximal garanti par WFQ

Par consquent, le dlai garanti par WFQ un flux ayant une courbe darrive

( ) tt += est la distance horizontale maximale entre la courbe darrive et la courbe deservice.Formellement, la borne maximale sur le dlai garanti par WFQ est [20] :

(6)Notons que le dlai augmente linairement avec la taille de la rafale du flux et diminue en

augmentant le taux de bande passante rserve. Par consquent, lors de larrive dune rafale de

taille importante, les paquets du flux peuvent rater leurs chances requises et la qualit de

service peut tre svrement dgrade. Nous remarquons que lquation (6) ne tient compte

daucune contrainte temporelle. Elle dpend uniquement du taux de partage de bande passante et

de la taille de rafale.

( ) ( ) ( )stsRtR +

CL

RD maxmax +=

D W F Q

R

T = L m ax /CT e m p ( s e c )

A r r ive s (b i t s )


47/84


48/84



implment des nouvelles bibliothques et modules qui prennent en compte le principe de

fonctionnement de WFQ dcrit dans le paragraphe prcdent [17].

Lintroduction de WFQ au niveau de notre script se ralise avec la commande $set

SchedulerMode WFQ en spcifiant les poids pour chaque file physique. Pour notre scnario, la

file modlisant le flux audio est la plus prioritaire, nous laffectons un taux de service, P1, gal

52%, le flux vido aura un coefficient de pondration, P2, gal 38% et la file la moins prioritaire

reprsentant les donnes a un coefficient, P3, gal 10%. Ainsi pour notre valuation de

DiffServ, nous nous intressons dans cette section un paramtre de qualit de service si

important qui est la bande passante. Pour cela, dans un premier temps, nous avons activ nos trois

sources gnrant leurs trafics selon les caractristiques dfinis dans le tableau II-1. Ilscommencent la transmission linstant t= 0 (s) et finissent t= 50 (s). Pendant ce temps de

simulation, nous avons mesur la bande passante rserve pour chaque flux en prsence de

lordonnanceur WFQ. La figure ci-dessous illustre la rpartition de cette ressource.

Fig II-8 : Partage de la bande passante (1)

En effet, daprs la figure II-8, nous remarquons bien que le partage de la capacit de lien

entre les diffrents flux est proportionnel aux poids attribus la file. En fait, en appliquant les

coefficients de pondration et suivant lquation (3), nous vrifions la conformit des rsultats.

En consquence, le flux le plus prioritaire, le trafic audio, normalement aura besoin dune bande


49/84



de lordre de 1 Mbit/s note BPaudio. Lexcs de rservation, associ ce flux, sera partag entre

les autres flux. En consquence, la bande rserve au flux vido, gale (C- BPaudio )*P2 /( P2+

P3)) est proche de 790kbit/s alors que celle de donnes a pour valeur 210kbit/s.

Ainsi, nous remarquons, que grce ces taux de service, nous avons favoris le flux audio

en lui assignant la bande passante dont il a besoin. Aussi, les mmes rsultats sont obtenus

lorsque la source de donnes gnre un flux selon le modle de trafic On/Off. Les priodes

dactivit On et de silence Off sont exponentiellement distribues avec les moyennes

ms500/1 On = et ms500/1 Off = . La figure-ci dessous illustre le partage de 2Mbit/s entre les trois

flux.

Fig II-9 : Partage de la bande passante ( Trafic On/Off)

Une autre simulation a t tablie pour mettre en vidence la gestion efficace de la bande

passante par lordonnanceur WFQ. En effet, Nous avons arrt la transmission de flux audio t=30 (s) puis nous lavons ractiv t= 50 (s) afin dobserver comment le surplus de la bande

passante est rparti entre les flux actifs. Le rsultat est prsent dans la courbe ci-dessous.


50/84



Fig II-10 : Leffet de lordonnanceur WFQ

En consquence de larrt t=(30s), nous observons une augmentation quitable de

lutilisation de la bande passante de lien selon les coefficients de pondration. De plus, le dbit

utile pour les deux flux (vido et donnes) atteint la valeur maximale suite cette interruption.

IV-2- Le taux de perte

Le scnario de simulation compare le taux de perte des paquets de flux vido et de

donnes pour le cas dordonnancement WFQ. En effet, plusieurs applications temps-rel telles

que la vido ont besoin de garanties particulirement de taux de perte et non seulement en terme

de bande passante. Ainsi, si le taux de perte est lev pour le flux vido, le processus de dcodage

peut rencontrer des problmes srieux pour maintenir une bonne qualit dimage qui peut tre

perturbe suite la perte des plusieurs informations significatives. Nous prsentons, dans la suite,

le taux de perte rsultant de notre simulation dans le tableau II-2. Nous rappelons que le taux deperte est le rapport entre le nombre de paquets perdus et le total des paquets envoy.

Temps de simulation

(sec)

Taux (%)- Flux

vido

Taux (%)- Flux de

donnes

0 0 0

10 0 50,4


51/84


52/84


53/84


54/84



V-2- La loi de commande

La commande est l'action dlibre sur un systme en vue d'atteindre des objectifs dfinis.

On parle de commande en boucle ferme (BF) dont l'action sur le systme command dpend de

la mesure de la grandeur commande y(t). Il s'agit d'une commande avec rebouclage de

l'information ou boucle de rtroaction. En consquence, les performances de ce type de

commande sont meilleures. On dfinit la commande comme suit :

(s)F(s)

(s)U= (s)F(s)(s)U = (7)

Avec F(s) reprsente la fonction de transfert et YY(t) c = . On reprsente, aussi, lerreur par la

figure ci dessous :

Fig II-14 : Prsentation de lerreur

V-2-1- La loi de commande proportionnelle

La loi de type Tout ou Rien peut tre amliore. Sil est en effet pertinent denvoyer

toute la puissance quand on est encore loin du but poursuivi, il convient de la rduire quand on

sapproche du rsultat atteindre. Laction U est alors dose proportion du rsultat atteint et

donc de lerreur. La loi de commande u (t) est proportionnelle lcart :

(8)

En effet, si K est grand, la correction est nergique donc rapide mais le risque de

dpassement et doscillations dans la boucle saccrot. Si K est petit, la correction est lente mais il

y a moins de risque doscillations. Nous reprsentons la variation de cette correction dans la

figure ci dessous :

KU =


55/84



t

K leve

K faible

Yc

Y(t)

Fig II-15 : Effet de la commande proportionnelle

Le rgulateur proportionnel assure une transmission instantane du signal derreur; dansce sens, son action est relativement dynamique. Sa commande ne dpend pas du pass, ni dune

tendance, mais simplement de ce qui se passe linstant prsent. Une limitation de ce type de

correcteur est son incapacit annuler notamment lerreur statique (vis--vis dune consigne

constante ou dune perturbation constante) [19]. En effet, si la commande u(t) appliquer au

systme doit tre non nulle afin que celui-ci puisse retrouver ou maintenir son tat dquilibre, il

est dans le mme temps ncessaire que lerreur soit non nulle.

V-2-2- La loi de commande intgrale

La loi de commande intgrale permet dassurer une commande U plus progressive.

Cette loi est de la forme :

(9)

La variable Ti est une constante de temps dintgration qui doit tre de mme ordre de

grandeur que T. Si Ti est trop petit, laction U monte trop vite sans laisser au systme le temps

de dmarrer progressivement. Par contre sil est grand, laction U monte trop lentement. La

commande intgrale ragit donc calmement aux variations brusques de lerreur et assure un

rattrapage progressif de la consigne. En effet, lorsque lerreur est devenue nulle, la commande ne

lest pas ncessairement. Le signal de commande dquilibre, ncessaire au processus, est

maintenu. Lintrt principal de ce correcteur est dajouter dans la chane de commande une

intgration. On sait que la prsence dune intgration annule lerreur statique pour une entre en

chelon. De ce fait, il permet donc damliorer la prcision.

dx(x)1/Tu(t)

0

i =


56/84



V-2-3- La loi de commande drive

Lintrt principal de la correction drive est son effet stabilisant. Elle soppose aux

grandes variations de lerreur (donc aux oscillations) et permet donc de stabiliser le systme et

damliorer le temps de rponse. Dans lindustrie, laction D nest jamais utilise seule mais

toujours associe aux autres actions. Laction du rgulateur drive nintervient que sur la drive

de lerreur. La loi de commande est de la forme :

+=

dt

(t)dT(t)(t)u d (10)

Laction drive permet une correction rapide de lerreur sans encourir le risque de

dpassement de consigne. Elle permet damliorer la stabilit et la rapidit du systme rgul.

V-3- Le rgulateur PID

Lintrt du correcteur PID est dintgrer les effets positifs des trois correcteurs

prcdents. La dtermination des coefficients K, Ti, Td du correcteur PID permet damliorer la

fois la prcision (Ti et K), la stabilit (Td) et la rapidit (Td, K) [18].

Le rglage dun PID est en gnral assez complexe, des mthodes pratiques de rglages

permettent dobtenir des bons rsultats. Le correcteur PID effectue un traitement de lerreur (t):

(11)

La transforme de la place de lexpression prcdente (11), en supposant toujours des conditions

initiales nulles, est sous cette forme:

(12)

Do nous tirons la fonction de transfert du correcteur PID.

(13)

++=

t

0

didtdTdx(x)1/T(t)Ku(t)

( ) ( )

+

+= PT

pT11pK(p)u d

i

( )

++==

PT

PTTPT1K

(p)

(p)U(p)C

i

2dii


57/84



Pour discrtiser cette loi, on pose t = k*, on choisit une approximation de la drive et

une autre cohrente pour le calcul de lintgrale. Si on appelle I(k) la valeur approche par la

mthode des rectangles suprieurs de lintgrale de (x) pendant k*, on aura :

(14)

Si on appelle D (k) la valeur approche de la drive de (x ) pendant k*, on aura :

(15)

Ainsi le PID aura la forme suivante :

(16)

VI- Conclusion

Le modle DiffServ, en introduisant la notion de classes et de priorits entre les flux, offre

des garanties strictes en terme de mtriques de qualit de service. Cependant, les priorits

affectes aux files sont statiques. Une alternative, permettant damliorer encore plus le niveau de

la qualit de service, est lintroduction de lapproche de rgulation dynamique des priorits.

Ce chapitre, avait pour objectif dvaluer les performances de DiffServ et de prsenter la

notion de la rgulation dans les systmes asservis. Ces informations seront utiles dans le chapitre

suivant qui sintressera limplmentation de lapproche de la rgulation dynamique des

coefficients de pondration des files de la discipline WFQ.

(i)I(k)ki

1i

==

=

++==

=

ki

1i

d

i1))(k(k)(T(i))

T((k)K(k)u

1)(k(k)(k)D

=


58/84


Chapitre III

Modlisation et implmentation de lapproche de

rgulation dans le modle DiffServ

I- Introduction

Dans les chapitres prcdents, nous avons introduit les paramtres quantitatifs de la

qualit de services. Parmi les exigences de certaines applications, comme la voix, en terme de

QoS, on trouve la bande passante et le dlai de transmission. Nous avons aussi tudi les

mcanismes de rgulation dans les systmes asservis. Dans ce chapitre, nous nous intressons

intgrer le principe du rgulateur PID avec le modle de DiffServ afin damliorer les

performances de diffrenciation des flux et le niveau de la qualit de service.

II- Aperu de lapproche de rgulation dans le modle DiffServ

Le but de notre approche est de tirer profit davantages dasservissement et de la

rgulation afin de raliser un module dajustement dynamique des coefficients de pondration des

files dattentes de lordonnanceur WFQ. En effet, cette rgulation est relative aux besoins des

applications et permet de favoriser un flux au dtriment de lautre. Lautomatisation de processus

dajustement et daffectation des priorits est dans le but datteindre certaines mtriques de

qualit de service. Lapproche peut tre prsente comme suit :

Fig III-1 Principe dajustement des coefficients

Rgulateur PID

WFQ

U

Pi

Pj

Pk

+

-

La Qos consigneYc

La QoS

mesure

Sortie


59/84

Modlisation et implmentation de lapproche de rgulation dans le modle DiffServ


Le rgulateur gnre une commande U qui ajustera les poids des files. Les classes

seront servies par le scheduler WFQ proportionnellement aux nouveaux coefficients. La

diffrence entre la valeur consigne (Yc) et la valeur mesure (Ym) sera, alors, transmise vers le

rgulateur PID. La valeur consigne dsigne gnralement un niveau de paramtre de QoS quon

lasservit, comme la bande passante, le dlai, la gigue. Ensuite, une commande, relative chaque

erreur calcule, est gnre par le correcteur PID. Cette commande ajustera le coefficient de

pondration propre chaque file et sert comme dterminant de sa priorit et son niveau de service

par WFQ. Le principe de la rgulation se rsume, ainsi, par les tapes suivantes :

- Spcification de la valeur consigne ou la mtrique quon veut asservir pour un flux i .

- Mesure de la mtrique.- Calcul de lerreur.

- Application de la commande de rgulation pour ajust

Documents

Pfe Mansour Hana