HAL Id: tel-00008540
https://tel.archives-ouvertes.fr/tel-00008540
Submitted on 18 Feb 2005
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of
sci-entific research documents, whether they are
pub-lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d’enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
TCP dans la Classe AF
Emmanuel Lochin
To cite this version:
Emmanuel Lochin. Qualité de Service dans l’Internet : Garantie de Débit TCP dans la Classe AF.
Réseaux et télécommunications [cs.NI]. Université Pierre et Marie Curie - Paris VI, 2004. Français.
�tel-00008540�
Spé ialité
SYSTÈMES INFORMATIQUES
présentée par
M. Emmanuel LOCHIN
pour obtenir legrade de
DOCTEUR de l'université Pierre et Marie CURIE
Qualité de servi e dans l'Internet :
Garantie de débit TCP dans la lasse AF
Présentée etsoutenue publiquementle 10/12/04devant lejury omposé de
Pr. Mi hel DIAZ Rapporteur
M. Fabri e GUILLEMIN Rapporteur M. Olivier BONAVENTURE Examinateur
M. Patri k COCQUET Examinateur
M. Pas al ANELLI Co-en adrant de thèse
Spé ialité
SYSTÈMES INFORMATIQUES
présentée par
M. Emmanuel LOCHIN
pour obtenir legrade de
DOCTEUR de l'université Pierre et Marie CURIE
Qualité de servi e dans l'Internet :
Garantie de débit TCP dans la lasse AF
Présentée etsoutenue publiquementle 10/12/04devant lejury omposé de
Pr. Mi hel DIAZ Rapporteur
M. Fabri e GUILLEMIN Rapporteur M. Olivier BONAVENTURE Examinateur
M. Patri k COCQUET Examinateur
M. Pas al ANELLI Co-en adrant de thèse
Konrad Lorentz 1905-1989 (Les huit pé hés apitaux denotre ivilisation, p.8,Flammarion)
J'aieula han edefaire ettethèsedansun adremotivéetsympathique,toutenexerçant montravail d'ingénieur ausein de l'équipe Réseauxet Performan es duLIP6.
Jetiens àremer ierSergeFdidadem'avoirproposéunethèseet dem'avoirfait on an e toutaulongde esannées. Jedois direqu'en tantqu'ingénieur ouqu'en tantque do tor-ant, je n'ai jamais eu à me sou ier des problèmes on ernant les moyens ou les budgets. Cela fa ilite grandement les hoses quant à la réalisation destravaux demandés. Je tiens également à remer ier Pas al Anelli pour la qualité de sonen adrement. J'ai toujours eu réponse à mes questions, soutien et en ouragements. Je souhaite à tout do torant de re evoir un en adrement de ette qualité et d'être aussi ompli e que j'ai pu l'être ave mesen adrantsde thèse. Bref,Pas al et Sergemer i.
Je tiensà remer iertousles membres de e jury: M. Mi helDiaz, dire teurde re her he du CNRS au LAAS à Toulouse, et M. Fabri e Guillemin de Fran e Télé om R & D Lannion, qui ont a epté d'être rapporteurs de mathèse, pour l'intérêt qu'ilsont portéà e travail. M. Olivier Bonaventure de l'Université atholiquede Louvainet M. Patri k Co quet, président de l'IPv6 Task For e Fran e et président de la so iété 6WIND, qui ont eu l'amabilité debienvouloir parti iper à e jury.
Jeremer ieégalementlesmembresdel'équiperéseauetperforman esave quij'aiappré ié travaillerpendant esannées,etplusparti ulièrement: toutel'équipesystème: Françoise, Konstantin, ma page de Manuel préférée : Manu Bouyer et Bruno Talavera qui, par son sens aiguisé de la ritique, m'a permis de faire évoluer mon travail. Les membres de l'équipe,notamment Anne ave quij'ai parti ulièrement appre ié detravailler et ave qui j'espèrebien ontinuer. Mi hel, toi, thésard, si tu te sens désespéré, va relativiser le tout danslebureaudeMi hel. SansoublierKim,Bruno, Kavé,Timur,Eri (pardon, Monsieur leDire teur),Brigitte, Bénédi teet Olivier. Je remer ie également Na eurdesdis ussions é lairées que nous avons eues ensemble et qui re onnaîtra sûrement quelques ourbes du hapitre 7. Les do torants passés et futurs et notamment Prométhée pour les pauses afé. Je tiens aussi à remer ier Clémentine et Véronique qui se sont o upées de toutes les démar hes administratives et qui, par leur e a ité, ontribuent grandement au bon fon tionnement dulaboratoire.
En n j'aimerais remer ier mes parents et ma famille de m'avoir laissé mener ma barque omme je le souhaitaiset Karine, qui a relu et orrigé ette thèse et m'a soutenu toutau longde e travail.
Lestravaux présentés dans ette thèse on ernent la qualité de servi edansles réseauxà ommutation de paquetsde grande dimension et plus spé i quement lagarantiede débit pour les ots TCP. L'ar hite ture à diéren iation de servi es, dé nie par l'IETF, dite DiServs'arti uleautourdetroisservi es:leservi egaranti, leservi eassuréet leservi e pardéfautditaumieux.Leservi eassuréaétéélaborépourservir les otsà ara tère élastique omme les ots TCP. Cependant, des problèmes subsistent en e qui on erne ettegarantiededébitpour etypede otsdans e servi e.Cesdernièresannées,uneort important aétéfaitpour améliorerlesmé anismes d'ordonnan ement,de lassi ation et de rejet au sein des routeurs a n qu'ils répondent au mieux à la spé i ation du servi e assuré.Malheureusement,leurs hoixde on eptionetla omplexitédeleurmiseen÷uvre esttrès souvent un frein àleur déploiement dans un Internet réel. Dans ette thèse,nous proposonsunesolutionoriginale de onditionnement des otsTCPpermettantdegarantir undébitàlafoispourdes otsindividuelsetdesgroupesde ots.Cettesolutionfon tionne quelquesoitlefa teur d'e helle.
Mots-Clés :
QualitédeServi e,diéren iationdeservi es,fa teurd'é helle,agrégationde ots,servi e assuré,TCP.
Thisworkfo useson qualityofservi ein larges ale pa ket swit hingnetworksand,more spe i ally, throughput guaranteefor TCP ows. The dierentiated ar hite ture, de ned by the IETF, also alled DiServ, provides three servi es : the guaranteed servi e, the assuredservi e and the besteort servi e. The assuredservi e was on eived for serving elasti ows su h as TCP ows. Nevertheless some problems persist when it omes to assuring a TCP throughput. These past years, a onsequent eort has been made in order to improve s heduling, lassi ation and dropping me hanisms in routers so that they mat h the assured servi e spe i ation as best as possible. Unfortunately, design hoi es and omplex implementation are frequent limitations to their deployment in the real Internet. In this thesis, we propose an original onditioning approa h for TCP ows allowingforaguaranteebothforsingleandaggregate TCP ows. Thissolutioniss alable.
Key Words:
1 Introdu tion 17
1.1 Evolution de l'Internet . . . 17
1.1.1 Contributions de ette thèse . . . 19
1.1.2 Plandudo ument . . . 20
2 La qualité de servi e dans l'Internet 21 2.1 Introdu tion . . . 21
2.2 LemodèleIntServ / RSVP . . . 21
2.2.1 RSVP . . . 22
2.3 LemodèleDiServ . . . 23
2.3.1 Organisationd'un réseauDiServ. . . 23
2.3.2 Classi ationet onditionnement dutra . . . 24
2.3.3 LesPHB . . . 25
2.4 Con lusiondu hapitre . . . 27
3 Mé anismes utiliséspour le traitement des servi es diéren iés 29 3.1 Introdu tion . . . 29
3.2 Cara tériserun ot . . . 30
3.3 Lesordonnan eurs . . . 31
3.3.1 Lesmé anismes à leunique, leFairQueuing . . . 31
3.3.2 Lesmé anismes à les multiples, l'algorithmeRound Robin . . . 34
3.3.3 Prévention dela ongestion : mé anismes de gestionde le d'attente 37 3.4 Con lusiondu hapitre . . . 42
4.2 Parti ularitésmatérielles et logi iellesde laplateforme . . . 43
4.3 Musi a IPet lastru ture d'a ueil . . . 44
4.3.1 Musi a IP . . . 44
4.3.2 La stru ture d'a ueil . . . 44
4.3.3 Trajetsuivi parun datagramme . . . 44
4.3.4 Interfa es . . . 46
4.4 Stru tured'un routeurgérant laQoS . . . 46
4.4.1 Elément de bordure . . . 47
4.4.2 Element de ÷ur . . . 49
4.4.3 Gestion et in uen e dutemps surle moduleQoS . . . 51
4.5 Con guration desrouteurs . . . 52
4.5.1 Organisation du réseauet interfa es à on gurer . . . 52
4.5.2 Con guration du omportement de bordure . . . 53
4.5.3 Con guration du omportement de ÷ur . . . 55
4.6 Con lusiondu hapitre . . . 56
5 Mesure sur la plateforme IRS 57 5.1 Introdu tion . . . 57
5.2 Methode d'evaluation desservi es. . . 57
5.2.1 Conditions d'études . . . 57
5.2.2 La plateforme detests . . . 58
5.3 Mesureset analyses desservi es . . . 60
5.3.1 Etude en isolationdesservi es . . . 60
5.3.2 Étude desservi es enprésen e mutuelle . . . 62
5.3.3 Étude du servi eAS pour les ots élastiques. . . 63
5.4 Con lusions du hapitre . . . 67
6 Garantie de débit TCP pour la lasse AF 69 6.1 Introdu tion . . . 69
6.2 Présentation duproblème . . . 69
6.3 Comment solutionner esproblèmes . . . 71
6.5.1 Rapport deproportionnalité débit/perte . . . 75
6.5.2 Marquage qualitatifdesmi ro ots [MSZ03℄ . . . 76
6.5.3 Marquage quantitatif basésurl'algorithmedu Time Sliding Window 76 6.5.4 Marquage adaptatif . . . 77
6.6 Con lusiondu hapitre . . . 79
7 Propositions de onditionneurs TCP pourla lasse AF 81 7.1 Introdu tion . . . 81
7.1.1 Quelles solutions? . . . 81
7.1.2 Motivation . . . 82
7.1.3 Aproposdu onditionnement de tra . . . 83
7.2 Laplateforme de tests . . . 84
7.3 LeDynami Shaper (DS) . . . 86
7.3.1 Evaluationdesperforman es du Dynami Shaper . . . 86
7.3.2 Con lusionpour le Dynami Shaper . . . 91
7.4 LePenalty Shaper (PS) . . . 92
7.4.1 Con eption duPenalty Shaper . . . 94
7.4.2 Ar hite ture. . . 95
7.4.3 Validationdu prin ipe . . . 97
7.4.4 Evaluationdesperforman es du Penalty Shaper . . . 98
7.4.5 Con lusionpour le PenaltyShaper . . . 102
7.5 AIMDPenalty Shaper (APS) . . . 103
7.5.1 Evaluationdesperforman es de l'AIMDPenalty Shaper . . . 104
7.5.2 Con lusionpour APS . . . 107
7.6 Con lusiondu hapitre . . . 108 8 Con lusion 109 8.1 Résumé . . . 109 8.2 Perspe tives . . . 110 Annexe A 113 Annexe B 115
Bibliographie 119
Liste des a ronymes 127
Liste des gures 128
Introdu tion
1.1 EVOLUTION DE L'INTERNET
En quittant le monde a adémique et militaire pour se développer dans la so iété, les ontraintes posées sur le servi e de transfert oert par l'Internet ont hangé. En eet, l'Internet ommer ial s'a ommode mal du servi e au mieux qui a prévalu depuis ses débuts. Les progrès deste hnologies numériques ont faitémerger des appli ationsqui posentdenouvelles ontraintes auservi ede ommuni ation. LaQualitédeServi e(QoS) est au ÷ur de es nouvelles demandes. La QoS s'exprime prin ipalement au travers des paramètres de bande passante, de laten e, de variation de la laten e également appelée gigueet de taux deperte. Au niveau dela ou he d'inter onnexionIP, laQoSdésigne les traitements appliqués aux ots de paquets a n qu'ils obtiennent un niveau de servi een adéquationave lademandeappli ative.Le hoixd'unservi ede ommuni ationpertinent pour l'appli ation poseleproblème de lasémantiquedesservi es oertspar un réseauau sens large.Ceux- idoivent être en nombre limité et doivent servir un large éventail d'ap-pli ations a tuelles ou futures. La multipli ité des servi es est un élément de omplexité danslaréalisation,lagestion et lalisibilitédesservi es.
Cette ré exionsur lenombre de servi es et leurs ara téristiques a été menée,il ya déjà quelquesannées,parlegroupedetravailIntegratedServi es(IntServ).Lasolutionretenue [BCS94 ℄s'appuiesurtrois servi esquel'on peuts hématiserdela manièresuivante :
leservi ede l'Internet lassique de ommuni ation dit aumieux ;
un servi e d'un Internet sans ongestion, surdimensionné, 'est-à-direpeu de pertes de paquets(duesauxerreursd'intégritéuniquement)etunelaten epro hed'unréseaupeu hargé. Ladé nition duservi ereste relativement peu pré ise;
un servi epour desutilisateursexigeantssurles délais.
L'ar hite tureDiServ,proposéeensuitepar[NJZ99 ℄,s'appuieaussisurundé oupagedes servi es en trois atégories assez similaires à elui proposé par IntServ. Ce dé oupage en
jours.Ilreposesurle onstatquelesappli ationssedivisents hématiquement,enfon tion de leurs exigen esde QoS, endeux atégories [Rob98 ℄:
Lesappli ationsintera tives, ommeparexemplelesappli ationsdistribuées,les appli- ationsdetype Contr le/Commande qui ee tuent un ontr le distantde systèmes mé aniques, les appli ations de téléphonie ou de vidéo onféren e. Plus généralement, ela on erne toutes les appli ations quien plus dudébit posent des ontraintes surles délaisde transitde haquepaquet et surlavariabilitéde es délais;
Lesappli ationsdites élastiques,qui onsistenttypiquement enuntransfertde hiers ( ommelestransfertsee tuésparleproto oleftp
1
),sontsensiblesuniquementautemps detransfert totaldu oudes hiers.La QoSrequise porte alors surledébitmoyen reçu au ours dutransfert,et non surledélai de transitde haquepaquet.
Cette division des appli ations en deux atégories identi e les garanties de QoS exigées d'un réseau entermesdedélai detransit pour undébitintrinsèquedonné,ou entermes de débit utile (goodput) indépendamment du délai de transit des paquets ou du débit instantané.
Les servi esproposés sontde trois atégories :
1. unservi eaumieux(BestEort:BE)traditionnelquial'avantaged'êtresimple à mettreen ÷uvreet é onomique;
2. unservi eàdébitassuré(Assured Servi e:AS)quiaméliorelaqualitéduservi eBE et destinéà mieuxtraiter une large gamme d'appli ations. Le servi eAS est onçu pour les otsà ara tère élastique. Ces ots ont un débit qui augmente tant qu'ily a des ressour esdisponibleset diminue quand une ongestion apparaît. Le débit de es otssedé ompose en deuxparties:
un débitminimumassuréet invariant. En asde ongestiondansle réseau,les paquetsde ettepartie étantmarqués omme inadéquatsàlaperte,ils nedoivent pas sourirde la ongestion;
un débit opportuniste, orrespondant à un débit de paquets opportunistes. Il onstitue lapartie variable du débit dite élastique . Au une garantie n'est apportéeà espaquets.Ceux- isonta heminésparleréseausurleprin ipeditau mieux . En asde ongestion, e sont espaquetsqui seront éliminésenpremier. Le débitopportunistedoitvarierenfon tiondel'étatdesressour esutilisées,d'où son ara tèred'élasti ité.Ildemandeàl'utilisateurduservi eréseaud'adapter son débit opportuniste à la apa ité du moment du réseau. En tout état de ause, le débit oert par e servi edoitêtre meilleurquele servi eBE.
3. un servi e à garanties fermes (Guaranteed Servi e : GS) pour des appli ations qui posent des ontraintes de QoS fortes et ne supportant pas de variations de la QoS. Ce servi e est destiné aux ots déterministes et temps réels. Il est onçu pour des ots ontinus ouréguliers et estsouvent assimilé à uneémulation de lignelouée. La faisabilité de es servi es et les problèmes de laQoS de manière générale sont étudiés dans de nombreux projets; itonsen parti ulierl'a tivité TF-TANT [TFT ℄ du projet eu-ropéen GEANT [GEA℄, le projet QBone [THD
+
99 ℄ et les projets européens TEQUILA [TEQ ℄, CADENUS [CAD℄ et AQUILA [AQU ℄, ontribuant tous à la proposition d'ar hi-te tures orientéesDiServ, dont le adregénéral estdé ni dans[BBC
+ 98 ℄. 1
1.1.1 Contributions de ette thèse
Lestravaux présentés dans ette thèse s'ins rivent dansla ontinuité du projet IRS 2
et portentsur la on eption, l'implémentation et lamesuredesperforman esd'une ar hite -turede ommuni ationgarantissant uneQoS de bout en bout.
Lesapportsde ette thèse sont:
le développement d'une ar hite ture de traitement diéren ié des paquets pour Inter-net, en onformité ave l'ar hite ture DiServ lassique. Une mise en ÷uvre de ette ar hite ture ainsiqu'une évaluationde sesperforman es seraprésentée;
faisant suiteauxmesures réaliséestoutd'abordave leproto ole UDP[GAC +
02℄, nous évalueronslesperforman esde ettear hite tureave leproto oleTCPauseinduservi e assuré(AS). Ces mesures mettront en éviden edeux points importants: le premier est que la ara térisation et le onditionnement de ots TCP par des mé anismes DiServ standards omme eux dé nis dans [BBC
+
98℄ ne sont pas su sants pour obtenir une garantie de débit moyen; le se ondest que es mé anismes de ara térisation de tra , omme letoken bu ket marker,sont detrès mauvaisdes ripteurs detra TCP; aprèsuneétudeexhaustivedespropositionsexistantes[NPE00,EGS02 ,KAJ01 ,FRK00,
HBF02 ℄ permettant d'apporter une réponse à e problème de garantie de débit, une lassi ation de es méthodes sera ee tuée. Cette lassi ation permettra d'identi er les diérents niveaux d'a tions possibleset leur faisabilité.Au traversde l'étude de es nouvelles méthodes de onditionnement, nous mettrons en éviden e que la omplexité des mesures né essaires au fon tionnement de es nouveaux algorithmes est un frein pour passer du adre de la simulation au adre d'une utilisation réelle. Nous verrons également que le onditionnement pose un gros problème de passage à l'é helle ar la granularité hoisie par es te hniques est le mi ro ot. En n, nous verrons que le point ommunmajeurdetoutes esméthodesproposéesestd'ee tuerunmarquageàlaperte plusagressifdelapartieopportunistedes ots.Or,[YR99℄amontréquel'augmentation du nombre de paquets marqués prioritaires à la perte n'est pas for ément la meilleure solution. Eneet, emarquagepeutprovoquerdefortesos illationsdudébitinstantané d'un ot TCP pouvant êtrepréjudi iable pour sondébit moyen;
partant de e onstat etdesmesures ee tuées,nousproposeronsune solutionen oppo-sition à es mé anismes. Tout d'abord, nous n'opèrerons passur le marquage d'un ot TCP. Nous utiliserons un mé anismede lissage de tra original, prenant en ompte la quantité detra opportuniste véhi uléeauniveau dugoulotd'étranglement duréseau, sanshypothèsesursalo alisation.Le onditionnementdutra s'ee tuerasurune gra-nulitépluslargepermettantunmeilleurpassageàl'é helleetseradon plusréalistepour une utilisation dans le adre d'un réseau réel. Plusieurs mesures illustreront l'e a ité de ette solution et sa apa ité à garantir un débit à un ot ou un ensemble de ots TCP au travers dela lasse assurée.
2
IRS(Ar hite tureIntégréedeRéseauxetServi es-dé embre1998-avril2001)estunprojetfrançais nan éparleRéseauNationaldelaRe her heenTélé ommuni ations(RNRT).
1.1.2 Plan du do ument
La thèse est stru turée en 7 hapitres de la façon suivante : le hapitre 2 dé nit le adre de ette thèse en donnant une présentation de la qualité de servi e dans l'Internet. Les mé anismes utilisés pour sa miseen ÷uvre seront étudiés au hapitre 3.Les prin ipes de l'ar hite ture DiServ ainsi qu'une implémentation et sa mise en oeuvre seront exposés au hapitre 4.Des mesures sur ette implémentation seront donnéesau hapitre 5.L'état de l'art des te hniques de garantie de débit d'un ot TCP au sein d'une lasse AF sera présenté au hapitre 6.Les obje tifs de ette étude feront suite. Les solutions envisagées, leur développement et leurs résultats seront exposés au hapitre 7. En on lusion, nous donnerons laperspe tivede travauxfuturs.
La qualité de servi e
dans l'Internet
2.1 INTRODUCTION
Ledéveloppement onsidérabledel'Internetetl'arrivéesurlemar héd'oresde onnexions à des débits supérieurs à 1Mbits/s ont ouvert la voie au développement de nombreuses appli ations multimédias.Ces appli ations possèdent des ontraintes qui ne sesatisferont pas du servi e dit au mieux (best-eort) fourni nativement par l'Internet. Même si ertainesde esappli ationssont onçuespourfon tionnerave eservi e,ellesontbesoin d'unminimumpourtravailler orre tement.D'autresappli ations, au ontraire, possèdent defortes ontraintes et nepeuvent s'adapterà e servi e.
Un réseau est dit à qualité de servi e lorsqu'il est apable de répondre aux attentes d'une appli ation à besoins spé i ques. Il doit être apable d'orir un servi e prévisible relativement onstant et d'être apable de répondre à des paramètres de performan e omme une garantie dedébit ouune garantie de délaide bout enbout.
Deux ar hite tures, basées sur des on epts totalement diérents, ont été proposées par l'IETF
1
a ndefournirlaqualitédeservi e.Nousdétailleronsdans e hapitrelesprin ipes de es deuxar hite tures.
2.2 LE MODÈLE INTSERV / RSVP
Historiquement, la première ar hite ture à qualité de servi e qui fût proposée pour l'In-ternet remonte à l'époque où l'idée d'intégration de servi eétait étudiée ave les réseaux ATM. L'ar hite ture à servi es intégrés appelée IntServ s'inspire de ette idée. Cette ap-pro he,proposéeparl'IETF,estdé niedanssesgrandeslignesdès1994dansleRFC1633
[BCS94 ℄ dont la partie modèle de servi e est très largement inspirée de [CSZ92℄. Cette ar hite turenepossédapaslesu èses omptéà ausedumanquede equelesanglais ap-pellent s alability (littéralement le passageà l'é helle). Cettete hnique de réservation deboutenbout édalapla eàuneautreappro hediteàdiéren iationdeservi es. Néan-moins,l'ar hite tureIntServaétéremiseaugoûtdujourparlaper éedesréseauxsans- l. Cette appro he étant onsidérée parfois omme laseule alternative possible on ernant la réservation deressour es sur esnouveauxréseaux à diusion ou omme seule possibilité permettant lanégo iation de ontrat de QoSentreréseaux laires et sans- l[RKV
+ 01℄.
Le but du groupede travail IntServ de l'IETF était latransformationde l'Internet a tuel enunréseau àintégrationdeservi es. L'ar hite tureIntServ s'organiseautourdu on ept de ots de données orrespondant à un ensemble de paquets résultant d'une appli ation utilisatri eetayantunbesoind'une ertaineQoS.A ndesatisfairelaQoSrequise,IntServ propose d'ee tuer une réservation des ressour es né essaires à l'établissement de elle- i via le proto ole de réservation de ressour es nommé RSVP. RSVP étant onstitué par l'information de ontr le delaQoS, elui- i proposedesdire tivesa n demettreen pla e la réservation mais ne dit pas omment lamettre en pla e, e domaine étant réservé aux routeursduréseauquiprennenten omptelasignalisationee tuéeparleproto oleRSVP. Pour sefaire,les routeursdisposent dequatrefon tions de ontr le du tra qui sont :
1. le proto ole de réservation de ressour es. Il solli ite, sur le hemin prédé ni par le proto ole de routage, des réservations de ressour es (bande passante et tampon mémoire) sur haque routeur traversé du réseau;
2. le ontr le d'admission.Il autorise ou refuse l'arrivée d'un nouveau ot muni de sa QoS sansperturber les QoSdesautres otsexistant;
3. le lassi ateur depaquets.Ilidenti elespaquetsdes otsdevantre evoirunservi e spé i que;
4. l'ordonnan eur de paquets. Il déterminel'ordre de servi edespaquets.
2.2.1 RSVP
L'IETFa onçuleproto oleRSVPpourlasignalisationdesbesoinsutilisateursauseind'un réseau Internet.Ilpeutêtre utilisépourassurerlaqualité deservi eet gérerlesressour es de transport du réseau pour les sessions point à point autrement appelée session uni ast et point àmultipoint : multi ast. RSVPest unsystèmede ontr le et de signalisationqui donne lapossibilitéde réserver labande passante né essaireau bon fon tionnement d'une appli ation. C'estunbesoinquitou he prin ipalement les uxmultimédias,plussensibles aux aléas de l'a heminement que les ux de données pures du fait de leurs ontraintes temporelles.
Une session RSVP estidenti ée par l'adresse du destinataire du ot de données (il s'agit d'une adresse IP uni ast ou multi ast), le numéro de port de destination et le proto ole utilisé(TCPouUDP).RSVPfon tionneave troistypesd'éléments:l'expéditeur,leréseau etledestinataire.L'expéditeurindiqueauréseaula ara térisationdu uxqu'ilvaenvoyer. Le réseau enregistrelesdemandes,les traite, noti eaudestinataire quedesmessagessont
la ré eption. C'est le destinataire du ot de données qui fait la demande de réservation en s'adressant à un pro essus RSVP lo al. La requête formulée, RSVP la transporte de routeurenrouteurdanslesensinversede eluiquevontemprunterlesdonnées on ernées. RSVP va maintenir un hemin ditàétat mou(softstate) artemporaire. Cedernier doit êtrerafraî hi régulièrementpour nepasdisparaître. RSVPne traitepasleroutage et à e titre, il peut être aussi asso ié ave le proto ole IP Multi ast, mono ou multi-émetteurs, lorsquedesé hangesontlieuauseind'ungrouped'ordinateursselonunmondeanalogueà elui utilisé dansle asde latélévision oude laradio. [Whi97 ℄donne untrès bontutorial sur e proto ole.
2.3 LE MODÈLE DIFFSERV
En réa tion auxlimites et aux di ultés de déploiement du modèle IntServ (notamment en e qui on erne sonpassage à l'é helle), un nouveau groupe de travail de l'IETF, The Dierentiated Servi es Working Group ou DiServ [BBC
+
98℄, a été hargé d'étudier une nouvelle appro he,appelée ladiéren iation de servi es.
Au ontrairedumodèleIntServquitraiteindépendamment haque ot,lemodèleDiServ proposedeséparerletra par lasses.Nousavonsdon aaireàunegranularitémoins ne maisquirésisteplusaufa teurd'é helle.Eneet,lagranularitépar otimpliquelaréa tion en haîne suivante : plus il ya d'utilisateurs, plus il ya de ots dans leréseau et plus il yad'étatsàmaintenir au seindesrouteurs.La onséquen e dire teestuneaugmentation dela harge desrouteursqui deviennent alors de moinsenmoinsperformants.
Cette ar hite ture repose sur leprin ipe de l'agrégation de ots de paquets en lasses de servi eset delagestiondes ressour espar lasse plut tquepar ot individuel[BBC
+ 98 ℄. Un ot individuel onsiste en une séquen ede paquetsissus d'unemême sour e de tra . Celui- i peut être tout aussi bien un site ou une appli ation. Ces ots sont regroupés en fon tion du servi e requis pour former desagrégats de ots. Le nombre d'agrégats de ots dépend des lasses de servi es oertes. L'agrégat de ots forme un ma ro ot. Par opposition, les otsindividuels sont appelés desmi ro ots.
2.3.1 Organisation d'un réseau DiServ
L'ar hite tureDiServdistinguelafrontièrede l'intérieurd'un domaine d'administration. Un domaine se dé nit omme une portion ontiguë de l'Internet ontr lée par une même autorité administrative. La frontière d'un domaine d'administration est marquée par un routeur de bordure. Ce routeur joue un r le supplémentaire de elui situé au ÷ur du domaine : elui du onditionnement du tra . Cette ar hite ture s'ins rit dans le même paradigmequel'Internet quiest:dereléguerla omplexitédanslesextrémitésduréseau et de laisser le ÷ur du réseau aussi simple que possible . Cette ar hite ture onduit à pro éder à un simple ordonnan ement des agrégats de ots au ÷ur du réseau et au ontr le de ots individuels enbordure.
Le groupe DiServpropose don d'abandonner letraitement du tra sous formede ots pour le ara tériser sous forme de lasses de tra
2
. Chaque lasse est identi ée par une valeur odéedansl'en-têteIP.Cette lassi ation doitsefairesurlesrouteursdebordures (edge router) à l'entrée du réseau. Un exemple de domaine DiServ estreprésenté sur la gure 2.1.
L'ar hite ture desservi esdiéren iésproposéedans[BBC +
98℄ ontient deuxtypes d'élé-mentsfon tionnels :
1. Lesélémentsde bordure(edge fun tions) :ils sont responsablesdela lassi a-tion des paquets et du onditionnement du tra . En bordure du domaine, 'est-à-direà l'arrivée dupremierélément a tif apablede traiterle hampDS (DS- apable),lespaquetsarrivantont dansleur hampTOS(Type Of Servi e pourIPv4) ou TCO (Tra Class O tet pour IPv6), une ertaine valeur DS. La marque d'un paquetidenti ela lassedetra auquelilappartient.Aprèssonmarquage,lepaquet est dit onditionné;
2. Les éléments du ÷ur ( ore fun tions) : ils sont responsables de l'envoi unique-ment.Quandunpaquet,marquédeson hampDS,arrivesurunrouteurDS- apable, elui- i estenvoyé aupro hainn÷udselonlePHB(Per HopBehaviour) asso iéà la lasse de tra . Le PHB in uen e la façon dont les tampons mémoires et la bande passante sont partagés parmi les diérentes lasses de tra . Une hoseimportante dans l'ar hite ture DiServ est que les PHB routeurs se basent uniquement sur le marquage depaquets, 'est-à-direla lasse detra auquel lepaquet appartient; en au un asils ne traiteront diéremment despaquetsde sour esdiérentes.
Le prin ipal avantage de ette ar hite ture est qu'il n'y a plus né essité de maintenir un état dessour eset desdestinations dansles routeursde ÷ur,d'oùun meilleurpassage à l'é helle.
2.3.2 Classi ation et onditionnement du tra
Le routeur de bordure aen hargelasurveillan e et le onditionnement dutra entrant. Ces tâ hessont omplexesetmettent enjeuunegrandevariétéde ontextes.Ellesservent à limiterlaquantitéde tra inje té par haqueutilisateur danssa lassedeservi e.Elles sont essentielles et limitent l'apparition de la ongestion dans la lasse de servi e. Les ontr les sur le tra entrant s'appliquent au niveau du ot utilisateur. La granularité du ot utilisateur et les paramètres du onditionnement de tra sont dé rits dans un pro l (TCA: Tra ConditioningAgreement). Lerésultat du onditionnement setraduit on rètement parunmarquagedespaquetsadmisdansledomaine,parlasuppressiondes paquets ex édentaires, ou par laremiseen forme du ot (assurerun espa ement temporel entreles paquets).
La lassi ation s'ee tue suivant une ou plusieurs valeurs ontenues dans l'en-tête IP (exemple:adressesour e -destination,portsour e -destination,proto olID,...). Celle- i faite, elle dirige le paquet vers la fon tion de marquage appropriée. Une fois les paquets
machine externe
routeur de bordure : élément de bordure + élément de coeur
région DiffServ
routeur de coeur : élément de coeur
domaine DiffServ
Fig.2.1 DomaineDiServ
marqués,ils sontenvoyésàleurdestination puisà haquerouteurDS- apable,ilsreçoivent leservi easso iéà leur lasse.
Le lassi ateurestparamétréparlesfon tionsduplande ontr le.Lestablesdemarquage despaquetssont on guréesenfon tiond'unetabled'adressessour esdonnéequiseraalors ommuniquéeau routeurde bordure.
Enplusde ette lassi ation/marquage, unmé anismede ontr ledutra estdé nipar legroupede travailDiServ. Ce ontr le dutra (tra pro le) a pour objetlaprise en omptedutauxdesortiedespaquetsa ndenepasdépasserunseuilmaximumdepaquets àenvoyer surleréseau.Ainsi,unmé anismedemesuredutra permetde savoirsile ot depaquetssortant orrespondaupro ldetra négo ié.Si e otdépasse un ertainseuil, ertainspaquetsserontmarqués ommemoinsprioritairesetserontautomatiquementjetés en as de ongestion dansleréseau omme l'illustre la gure2.2.
2.3.3 Les PHB
Le traitement des paquets par les routeurs du domaine est dé ni par le omportement de relayage (PHB : Per-Hop Behavior). La séle tion du PHB est fon tion de la marque ontenue dans l'en-tête du paquet. En plus du omportement standard a tuel dit DE (Default)utilisé par leservi eBE,deuxPHBsont disponiblesEF(Expedited Forwarding) [DCB
+
02 ℄ et AF (Assured Forwarding) [HBWW99℄. Le PHB EF permet de réaliser un servi ede transfert à forte ontrainte temporelletandis quele PHB AFassureà ertains
TOS, ...
Token Bucket
Leaky Bucket
Classification
paquets et
classification
sur @IP, ports,
Action
Vérification
Arrivée des
Lissage
Marquage
Rejet
000000
000000
000000
000000
000000
111111
111111
111111
111111
111111
Fig.2.2 Classi ation,marquageet onditionnementdutra auniveauduedgerouter
Expedited forwarding
Le PHB EF permet de mettreen ÷uvre une lasse de servi esurdimensionnée, au même titre qu'un lien privé virtuel, permettant d'obtenir des performan es très supérieures à elledu lassiqueréseaubest-eort.Deux lassesdetraitementssontproposées:une lasse à très faible délai et sans perte et une lasse best-eort lassique.Ce PHB doit orir un servi edeboutenboutave unegarantiedebandepassanteàtauxdeperte,délaietgigue faible. Il a été tout d'abord dé ni d'une manière relativement intuitive dans [J
+
99℄. Une étudeanalytiqueamontréqueleservi edeboutenbout attenduétaitimpossibleàmettre en ÷uvre dans ertains as parti uliers [BBC
+
01℄. Sa dé nition a alors été remaniée de manière plus omplexe et formelle dans [DCB
+
02 ℄. Une bonne façon d'illustrer e PHB est la mise en ÷uvre que l'on peut faire de e servi e ave un ordonnan eur omme le priority queuing (voir se tion 3.3.2). La le EF est stri tement prioritaire sur la le BE (best-eort). Dans [Fer00 ℄, une implémentation de e type est omparée ave un autre ordonnan eur de paquets. Ilest montréqu'en ontr lant laquantité de tra prioritaire à laquelleles usagerssont abonnés,il estpossibled'assurer quele tra EFarriveen petite quantité sur les routeurs et qu'il ne sature pasle débit de sortie. Ainsi, la le BE reçoit, malgré saprioritéinférieure, unservi esatisfaisant.
Assured Forwarding
Il s'agitenfaitnond'unPHBmaisd'unefamilledePHBs(PHBgroup).Quatre lassesde traitement assurésont dé nies, ha une omprenant troisniveauxde priorité spatiale (droppre eden e) [HBWW99℄.Dans un n÷uddonné, leniveau d'assuran e de traitement d'un paquet dépend de la bande passante allouée à la lasse, de la harge a tuelle de la lasse et delapriorité spatiale du paquet.
1. réduire la ongestion delong terme dansla lasse;
2. a epter les rafales( ongestion à ourt terme);
3. traiter identiquement les mi ro ots ayant desdébits moyens identiques (i.e. ne pas défavoriserun mi ro otbursty).
Ce iimpliquela miseen÷uvre d'un algorithmede gestiona tive de la le, dutype RED (Random Early Dete tion) [FJ93 ℄.
Le servi efourni par haque lasse peut être modulé par leréglage des paramètres de et algorithme en onjon tion ave eux du onditionnement de tra opéré aux n÷uds de bordure. Des marqueurs à trois ouleurs sont proposés [HG99a , HG99b℄ pour diviser letra de haque lasse selon lestroispriorités.
2.4 CONCLUSION DU CHAPITRE
Nousavonsprésentédans e hapitredeuxar hite turestrèsdiérentes.LemodèleDiServ se distingue du modèle IntServ de part son meilleur passage à l'é helle (s alability). En eet, en séparant le tra en un nombre réduit de lasses et en repoussant la omplexité ( lassi ation et onditionnement) aux extrémités du réseau, e modèle atteint l'obje tif de passage à l'é helle pour le plan de données. Par ontre, par rapport à IntServ il est lair que l'on perd soit en exibilité soit en fermeté des garanties. De plus, à moins de se ontenter d'une forte sous-utilisation du réseau (i.e. onditionner le tra de manière très onservatri e), le problème du plan de ontr le reste entier. Dans le as de tra multi ast,les hosesse ompliquent en oreetau une appro hen'est proposéesurlafaçon de dimensionner le réseau et de onditionner e type de tra . Clairement, le groupe de travail se trouve onfronté sur e point à des problèmes très di iles à résoudre relevant dudomaine de lare her he.
Mé anismes utilisés pour le traitement
des servi es diéren iés
3.1 INTRODUCTION
La gestion des les d'attente est né essaire pour équilibrer le tra [BCC +
98 ℄. Elle évite lamonopolisationd'une le d'attente par un seul ot. Une simple gestion de les n'évite pas qu'elles soient pleines pour des périodes longues, alors que pour avoir de faibles dé-lais il est souhaitable que les les ne soient pas trop hargées. En eet, de petites les d'attente réduisent les délais de transmission. Les obje tifs de lamémorisation du réseau sontd'absorber lespointesdetra , degérerles ontentions d'a ès(parexemple,lorsque deuxpaquets demandent à utiliserune ligne en même temps, les demandes sont alors sé-rialisées),derégulerles tra sissusdelignesàvitessediérente (parexemple,d'uneligne à 100Mbits/s vers une ligne à 10Mbits/s). En revan he, l'obje tif du réseau à qualité de servi e n'est pas le même que elui du réseau dit best eort . Pour es raisons, des mé anismessupplémentaires omplètent lasimplegestionde lesd'attentesde sortie.Ces mé anismes permettent de diminuer le nombre de datagrammes éliminés et le délai de bout enboutainsiqued'éviterleremplissagepermanentdes lesd'attente et elatouten gardant une bonne utilisation duréseau.
Le [BCC +
98℄ dé nit deux types d'algorithmes de ontr le de ongestion : la gestion des les et l'ordonnan ement. Le premier gère la taille de la le en éliminant des paquets si né essaire tandis que le se ond détermine le pro hain paquet à envoyer sur le lien. Ces deux algorithmes sont utilisés pour gérer le temps d'a ès au support et par onséquent, ledébit d'un ot dedonnées.
Taille de la file
Taille
Taux de régénération
des jetons : r
C
du seau : B
Fig.3.1Token Bu ket
3.2 CARACTÉRISER UN FLOT
Le but dela ara térisationdu tra estde véri er quelademandene soitpassupérieure à la ressour e disponible a n de ne pas saturer le réseau. Cette ara térisation va être ensuite utilisée par la politique de tra qui se hargera d'autoriser ou de refuserl'envoi des paquets à l'intérieur du réseau. Dans un réseau à qualité de servi e, il est né essaire de ontr ler letra entrant a n d'assurer à ha un des ots laqualité demandée. Parmi les ara téristiques qui vont in uer de façon signi ative surle omportement du réseau, l'intensitéetlasporadi itédutra sontdepremièreimportan e.Ce ontr ledetra vise à limiterlevolume et l'intensité dutra émispar unesour e. Pour sefaire,trois ritères importants vont entrer enjeu :
1. ledébit moyen : r;
2. ledébit rête : C;
3. la taille maximum de la rafale : elle limite la quantité de données émise au débit rête : B.
Pour se faire, on va utiliser un mé anisme de ara térisation de tra omme le seau à jetons(tokenbu ket)a nde ontr lerledébitmoyen etlatailledesrafales.A nd'obtenir le débit rête, les implémentations a tuelles sérialisent un se ond seauà jetons. Ainsi, on ontr lera levolumede tra entrant dansleréseauet ledébitave lequelil esttransmis. [Kes97℄ distingue le seau à jetons,utilisé pour ara tériser un tra au régulateur à seau per é(leakybu ketregulator)quiluiestunrégulateurdetra onstituéd'unseauàjetons et de mémoirestampons.
Le prin ipe du seau à jetons est le suivant : le tra ne traverse pas dire tement le seau mais esttransmis surla basede jetons présentsdansle seau. Ce mé anismepermet à un tra en rafaled'êtretransmistantqu'il yadesjetonsdansla led'attente, eux- iayant pu être a umulés en situation de réseau peu hargé. Un jeton orrespond à un nombre de bits donnés. Comme nousle montre la gure 3.1, un token bu ket onsiste en un seau de profondeur B ( orrespondant au nombre de jetons qu'il peut sto ker), onstamment remplipardesjetonsayantpourtauxd'arrivée r( orrespondantaudébitmoyen).Chaque jetonarrivantlaissesortirunpaquet dedonnéesentrant dela led'attente. Cepaquetest alors ea é du seau. Pour omprendre lerésultat obtenu prenons l'exemple suivant : soit
1. plein: le paquetest envoyé et b jetonssont retirés duseau;
2. vide : le paquet doit attendre que le seau se remplisse à nouveau de b jetons pour êtreenvoyé;
3. partiellement plein : il y a B jetons dans le seau. Si b 6 B, le paquet est envoyé immédiatement sinon, il doit attendre la régénération de b B jetons avant d'être envoyé.
Onparle alors de ots (r;B) régulés.
3.3 LES ORDONNANCEURS
Dans lepré édent hapitre, nous avonsvu que letraitement diéren ié despaquets dans lemodèleDiServ orrespond à la lassi ation de ots en lasses de servi e et à l'intro-du tion de priorités à l'intérieur de es ots. Cette partie va s'atta her aux algorithmes d'ordonnan ement.Ils sontutilisés a n de ontr ler ladistributionde ressour esentreles diérentes lasses de servi e. Plusieurs te hniques ont été développées pour ontr ler le partagede ressour es,pourisoler des lasses deservi eoupourréduire letemps d'attente des paquets dans les les. Il en existe deux appro hes : l'appro he mono ou multi les. Nousallonsprésenterdans ettepartie les généralitésde esdeux appro hes.
3.3.1 Les mé anismes à le unique, le Fair Queuing
Cesmé anismes sebasentsurlanotiond'estampilles temporelles quidéterminent lepoint d'insertiond'unpaquetdansune leunique.Cetteestampilleest al uléeàpartirdupoids attribuéà la lasse deservi e, de lalongueur dupaquet et de l'intera tion ave les autres lasses a tivessurlelien.
Weighted Fair Queuing (WFQ)
Le modèle idéal du partage de débit entre ots/sessionsest GPS : Generalised Pro essor Sharing, dans lequel on suppose pouvoir partager le débit disponible de façon uide et ontinue. [PG92 ℄dé nit e modèle théoriquede multiplexage de ots/sessionsde lafaçon suivante :unserveur GPS onserveletravail(work onserving) etopèreàundébit xeC. Unserveur dit" onservateurdutravail"signi equ'ildoitêtreo upésiilyadespaquets en attente dans le système. Il est ara térisé par des nombres réels positifs
1 ; 2 ;::: n . SoitS i
( ;t)laquantité deservi ereçuepar lasessionidansl'intervallede temps[ ;t℄.Le serveur GPSest dé nitelque :
S i ( ;t) S j ( ;t) > i j ave ;j =1;2;:::N (3.1)
pour toutes sessionsipossédantdu tra en attente surl'intervalle [ ;t℄. Ensommant:
Φ1 = 1
176
64
32
256
64
352
32
288
F(k) 1
L(k) 1
F(k) 0
L(k) 0
16
32
32
32
48
64
64
32
80
32
64
96
112
64
32
128
32
128
128
32
144
32
32
160
64
224
128
32
32
160
32
128
112
64
64
96
80
32
64
32
48
64
32
32
16
32
64
224
32
256
32
288
352
64
32
144
176
64
Flot 0
Φ0 = 2
Flot 1
Fig.3.2Ordonnan ementparWeightedFairQueuing
on obtient pour toutes lessessionsj :
S i ( ;t) X j i X S j ( ;t) (3.3) S i ( ;t) i P j C (t ) (3.4)
Ainsi, une partde labande passante est garantie àlasession i:
g i = i P j C (3.5)
Si l'on assureque P
j
61,par exemple grâ e à un ontr le d'admission, ette garantie s'exprime alors en termes de bande passante absolue. Chaque lasse dans e modèle dis-pose d'un débit minimum garanti, et les lasses ex édant leur débit minimum garanti se partagent ledébit ex édentaire équitablement.
[PG92℄proposentuneémulationdeGPSpourdesréseauxréels,quinepeuventtransmettre qu'unpaquetàlafois.CetteémulationportelenomdePGPSpour pa ketby pa ket GPS. L'idée est de servir les paquets en les triant sur leur date de n de transmission sous GPS, 'est à dire que les paquets seront émis dans l'ordre où ils nissent (et non pas ommen ent) leur transmission ave un serveur GPS. Il va don falloir trier les paquets ave uneestampilletemporelle orrespondantàladatedeleur ndetransmissionenGPS.
WFQ[BZ96b ℄, SCFQ[Gol94 ℄ou en oreSFQ[GVC96 ℄sont desmé anismes quisebasent sur ette notion d'estampille temporelle. Cette estampille détermine le point d'insertion d'un paquetdansune leunique.Elle est al uléeàpartir dupoidsattribuéàla lassede servi e, de la longueur du paquet et de l'intera tion ave les autres lasses a tives sur le lien à partir dela formulesuivante :
F k i = 1 i L k i +F k 1 i ave F i 0 initialiséàzéro (3.6) ave F k i l'estampilleduk eme paquetdu oti, i
lepoidsattribuéau otet L k i
lalongueur dupaquet.LesestampillesF
k 1 i
etF k i
orrespondent respe tivementauxdatesauxquelles lepaquet ommen eetterminesonservi e.Lepoidsd'une lasse,
i
pour en-si pour tout i on a i
=1.La gure 3.2 donne une illustration de e al ul pour deux otsnumérotés0 et 1de poids respe tifs
0 et
1
et d'estampilles temporelles respe tives F 0 etF 1 . LepoidsattribuéàF 0
estledoublede elui deF 1
et lespaquetsont unetaille identique:L
0 =L
1
.Malgrélatailleidentiquedespaquets, le ot 1adesestampillesdeux foisplusgrandesquele ot0.L'étatdela lereprésentéeenbasdela guremontrequeles paquetsdu ot 0sontee tivementservisenpremier. Alongterme,le ot 0doitobserver undébit deuxfois plusimportant quele ot1.
La formule (3.6) présente deux défauts. Tout d'abord, elle ne prend pas en ompte le temps d'arrivée des paquets. Si un ux reste ina tif pendant que d'autres évoluent, la valeur desestampilles F
k i
est désyn hronisée. Lors de sonréveil, le ot severra attribuer desestampilles de faible valeur et obtiendra une quantité de ressour es ne orrespondant plusàsonpoids
i
.Deuxièmement,laformuleneprendpasen omptelaprésen ed'autres ots, or ette information est indispensable pour al uler laquantité exa tede ressour es qu'un ot peut obtenir. Des te hniques plus avan ées introduisent la notion de temps virtuel pour ara tériser l'a élération duservi e quand ertains ots ne sont pasa tifsà uninstant donné.Lafon tion de tempsvirtuel permet dedé nir letempsqueles paquets restentdansune led'attente. Elledé nitl'a élérationduservi equand ertaines lasses deservi e sontabsentes. Le temps virtuel,v( ),est al uléde lafaçon suivante :
v( 0 ) v( )= 1 P a tifs i ( 0 ) (3.7) ave 0
et représentantdesintervallesdetempsoùl'ensemblede otsa tifsreste onstant. Posons quele k
eme
paquet de lasession i arrive au temps a k i et a pour taille L k i . Ave le serveur GPS, ona : F k i = 1 i L k i +max(F k 1 i ;v(a k i )) (3.8)
PGPS et WFQ [BZ96b ℄ sont le même algorithme donnant une approximation du GPS. Lesauteursdu WFQle on evaient omme uneémulation d'untourniquet bità bit,aussi la notion de temps virtuel est rempla ée par le numéro du y le de servi e (à haque y le un bit est servi pour haque session a tive). L'avantage de la dis ipline WFQ est qu'elle permet d'obtenir un degré d'équité. Il est possible d'obtenir une bande passante par onnexionainsique desbornes de délais.Les rafalessont lisséeset il n'ya pasbesoin de faire un ontr le de tra en amont [Kes97℄. En revan he le al ul des estampilles est omplexe,ilestné essaired'avoirunétatpar onnexionet ilfaut lasserlespaquetsavant delesservir.Deplus,depetitesbornesdedélaisdemandentunelargeréservationdebande passante.
WF 2
Q
Une versionaméliorée de WFQajoute une onditionpour éviter à ertains uxde trans-mettre en rafale : dans la dis ipline WF
2
Q [BZ96a ℄ les paquets ne sont éligibles à la transmissionques'ilsauraient déjà ommen é leurtransmissiondanslemodèleGPS.Elle
Flot A
000
000
000
000
000
000
111
111
111
111
111
111
000
000
000
000
000
000
111
111
111
111
111
111
000
000
000
000
000
000
111
111
111
111
111
111
000000
000000
000000
000000
000000
000000
111111
111111
111111
111111
111111
111111
000000
000000
000000
000000
000000
000000
111111
111111
111111
111111
111111
111111
000000
000000
000000
000000
000000
000000
111111
111111
111111
111111
111111
111111
00000
00000
00000
00000
00000
00000
11111
11111
11111
11111
11111
11111
00000
00000
00000
00000
00000
00000
11111
11111
11111
11111
11111
11111
00000
00000
00000
00000
00000
00000
11111
11111
11111
11111
11111
11111
00000
00000
00000
00000
00000
00000
11111
11111
11111
11111
11111
11111
0000000000
0000000000
0000000000
0000000000
0000000000
0000000000
1111111111
1111111111
1111111111
1111111111
1111111111
1111111111
000
000
000
000
111
111
111
111
000
000
000
000
111
111
111
111
000
000
000
000
111
111
111
111
00000
00000
00000
00000
00000
00000
11111
11111
11111
11111
11111
11111
000
000
000
000
111
111
111
111
000
000
000
000
000
000
111
111
111
111
111
111
000
000
000
000
000
000
111
111
111
111
111
111
WF2Q+
File 1
File 0
Flot C
Flot D
Flot B
Fig. 3.3WF 2 Q+à lesmultiplespetites qui la rend plus équitable que WFQ. Son prin ipal désavantage est l'emploi d'un régulateur pour traiter les paquetsinéligibles.
WF 2 Q+ WF 2 Q+estunra nement de WF 2
Q.L'aspe t léestl'utilisation d'unsystèmed'horloge virtuelle qui garantit toutes les propriétés de WF
2
Qtouten simpli ant onsidérablement les al uls, les ramenant à O(n) ave n : nombre de les.Il estdé rit dans[BZ97 ℄.
Con lusion
La dis iplineWFQestfréquemmentimplémentée; onlatrouvepar exempledansde nom-breux ommutateursATM ommeordonnan eurpourles onduitsABR.Elleposetoutefois deux problèmes : le temps de al ul, quivarie en O(log(n)) où nest lenombre de lasses a tives dans le lien [SV96 ℄ et le fait qu'elle peut introduire des rafales en prenant de l'avan e pour ertains uxsurl'idéal GPS.En n, l'insertion ordonnée despaquets dans une leunique est uneopération oûteuse.
A n de s'aran hir de la omplexité de l'insertion ordonnée des paquets dans une le unique, les implémentations a tuelles proposent de déporter le problème en utilisant la lassi ation surplusieurs les.LesnouvellesimplémentationsdeWFQ,toutengardantle prin iped'estampilletemporelle,utilisentplusieurs lesd'attentespour lasserunensemble de tra parti ulier, e qui augmente son e a ité. De plus, à ause des simpli ations de al ul apportées par WF
2
Q+, l'on préfère son utilisation à elui de WFQ. C'est le as notamment de l'implémentation dummynet de Luigi Rizzo [Riz97 ℄. Nous verrons en hapitre4quenousutiliseronsunedis iplineWF
2
Q+à lesmultiplespourletraitementde la lasseAFet DE(Default) dansnotre implémentationd'ar hite ture DiServ.La gure 3.3illustreleprin iped'utilisationdeladis iplineWF
2
Q+à lesmultiples.Sur ette gure, les otssont lassi és dansdeux les distin tes: la le0et la le1.La lassi ation peut êtrefaite parexemple surdeuxadressesIPsour ediérentes. L'estampillonnagetemporel est alors réalisé sur es deux ots. Il n'y a don plus besoin d'un état par onnexions entrantes ar elles- i seretrouvent agrégéessous formede deux ots distin ts.
3.3.2 Les mé anismes à les multiples, l'algorithme Round Robin
Serveur
Classifier
Fig.3.4RoundRobin
Serveur
File d’attente de priorité haute
File d’attente de priorité basse
Classifier
Fig.3.5 PriorityQueuing
basedel'algorithmeRound Robin.Lagranularitéestauniveaudupaquet.L'ordonnan eur par ourt en séquen e les les et prend le premier élément. Si une le est vide, il passe à la lesuivante.L'équitéoertepar emé anismedépenddelataillemoyenne despaquets dans haque le: une le ontenant despaquets deuxfoisplus grosqueles autresobtient deux fois plus de bande passante. Il est don né essaire de modi er et algorithme pour limiter le nombre d'o tets que l'ordonnan eur peut retirer de haque le a n d'assurer l'équité.
PriorityQueuing
Ave e type d'ordonnan ement, les paquets arrivant sur le lien de sortie sont lassi és en une, deux, voire plusieurs lasses sur la le de sortie. La lasse d'un paquet dépend alors d'un marquage expli ite se trouvant dans l'en-tête même de elui- i. Par exemple, en prenant en ompte le hamp TOS d'IPv4, ou alors en prenant en ompte les autres données présentes nativement dans l'en-tête omme l'adresse sour e/destination, le port sour e/destination,outoutautre ritère.Commelemontrela gure3.5, haque lasseasa propre led'attente.Leserveur hoisirad'abordunpaquetsetrouvantdansla led'attente haute priorité si elle- i est non vide, avant eux se trouvant dans la le basse priorité. La granularité de lassi ation se basant surl'en-tête même du paquet estassez exible. En revan he, e système implique une dégradation des performan es. Il peut y avoir un problème lorsque le tra hautepriorité est très important; en eet,il peut y avoir rejet despaquetsdutra normal à ausedelatailledela led'attentebassepriorité.Onparle alors de famine. [FC00 ℄ présente une étude omparative intéressante entre la dis ipline WFQet PQpour la lasse EF.
Class Based Queuing
C'estunevariationdeWFQquiutiliseégalementuntourniquetsurplusieurs lesmaisun lassi ateur en amont de la batterie de le va s'intéresser à lassi er haque paquet en fon tion de sa lasse. Il n'y a don plus de lassi ation surle ot. Grâ eau round robin ensortiedes les,onévitequ'uneseule lassedetra nemonopolisetouteslesressour es.
Dans[FJ95 ℄,SallyFloydetVanJa obson proposent une ar hite turebaséesurlepartage de liens(link sharing) . Ce dé oupage de labande passante peut être faite en prenant en ompte :
Lien
audio
video
20%
ftp
telnet
50%
20%
10%
0%
Fig. 3.6 Partage delien entre plusieurs lasses de servi es
Lien
org A
org B
org C
ftp
telnet
UDP
TCP
Fig.3.7 Partagehiérar hiséd'unlien
Lestypesde tra sappli atifs (telnet, ftp,mail, ...), Lesdiérentes organisationspartageant lelien.
Lebutdulinksharing estla lassi ationde esdiérentstypesdetra a nd'opéreràun partage delabande passanteentreeux ommelemontrela gure3.6. Chaque lasse, ave une demande orrespondante à ses besoins, doit être en mesure de re evoir approximati-vement sa bande passante allouée durant un ertain intervalle de temps lorsque le réseau est ongestionné.Sur la gure3.6, lelink-sharing nedonne au une garantiede bande pas-sante pour letra mailen asde ongestion. Le partage peut également êtrehiérar hisé, par exemple, entre diverses organisations omme le montre la gure 3.7. Une part de la bande passante estdon attribuée à haque niveau. La gestion des les met en ÷uvre les diérentes variantes de gestion des listes de pro essus : priorité, temps partagé. En fait, pour les as extrêmes, il est utile de pouvoir onsidérer qu'un ertain type de tra est éliminable. Les mé anismes de partage dans[FJ95 ℄ ne tentent pas de fournir un ontr le de ongestion au niveau des feuilles de l'arbre ( orrespondant à une lasse de tra ). Ces mé anismesétantàimplémenterparl'ordonnan eurgénéralàl'entréeduréseau.[WGC95 ℄ donne de plusamples expli ationssurl'implémentation de este hniques.
Uneautreappro he onsisteàralentirles uxplut tqu'àgérerlesprioritésoulapénuriele asé héant.Le ralentissement se ommandeàl'aidede messagesICMPde ralentissement émis depuis un routeur intermédiaire vers l'émetteur initial du message.Ces messages ne remontent ependant pasàl'appli ation et nesont don pasfor ément suivisd'eet,d'où l'idée du lisseur de tra (tra shaper) qui diminue la taille de lafenêtre d'anti ipation dansl'en-têteTCP defaçonàréduire ledébit de ertains ux.Le lassementdestra sse fait selon diérents ritères : hamp TOS, adresses IP sour e et/oudestination, numéros de ports UDPouTCP quipermettent d'identi er les ux. Ondistingueles appli ationsà tra tempsréel oulesappli ationsdu typemessagerieau tra moinsurgent. Cesmodes
le hampTOSpourlesdatagrammesqui ir ulentdefaçonindépendante.Selon[BCC 98℄ lanoti ation et laprise en ompte delarégulation par IPsont à re ommander.
Clark-Shenker-Zhang
[CSZ92 ℄ proposeune ar hite ture pour les réseaux de type ISPN 1
supportant deux types distin tsde servi estemps réel :
1. Les servi es garantis : 'est la forme traditionnelle des servi es temps réels bornés par des ontraintes de délai orrespondant au pire des as;
2. Lesservi esprédi tifs:ilsutilisent desmesuresdeperforman eduréseauparlebiais de al ul debornesde délai d'a heminement de paquets.
Les on eptsdé ritsdansl'arti les'intéressenttoutparti ulièrementauxservi esprédi tifs ainsi qu'aux paramètres d'installation passés entre le réseau et la sour e. Notamment, l'interfa e de servi edoitin lure:
1. Une ara térisationde lasour e;
2. Une des riptiondela QoSqueleréseau est enmesure d'orir.
La dernièrepiè e de ette ar hite ture est l'ordonnan eur depaquetsutilisé.
L'idée prin ipale de [CSZ92 ℄ est de réer des ots WFQ pour haque servi e garanti et d'allouerlereste delabandepassanteàun ow-0.Le ow-0 omprend letra deservi es prédi tifsetletra best eort.Ce ot estgéréparunordonnan eurdeprioritéattribuant labandepassante hautepriorité autra prédi tif,lereste étant partagépar letra best eort.
[CSZ92 ℄utiliselemé anismedutokenbu ket a n de ara térisersontra (voirlase tion 3.2). Une sour e de tra est onforme à un token bu ket (r,b) si il y a toujours assez de jetons dans le seau haque fois qu'un paquet est généré. L'ar hite ture [CSZ92 ℄ suppose également queles ots soient passéspar un mé anisme de ontr le d'admission à l'entrée duréseau.
3.3.3 Prévention de la ongestion : mé anismes de gestion de le d'at-tente
Par rapport aux mé anismes d'ordonna ement qui dé ident du paquet à transmettre, le r ledesmé anismesdegestionde led'attenteestdedéterminer lespaquetsàéliminerau seind'unemême lasseen asde ongestion.Lerejetd'unpaquetestsoitdûàla ongestion ouàdeste hniquesdepréventiondela ongestion.Ilexistedespropositions[Jai89 ,WC91 ℄ dans lesquelles le proto ole de transmission aux extrémités ontr le la vitesse d'émission a n de réduire la taille des les dans les routeurs. Ces solutions sont di iles à mettre en ÷uvre et leur e a ité est relative. Selon [FJ93 ℄, 'est au sein du routeur qu'est le meilleur endroit pour ontr ler l'évolution des les d'attente. Nousallons dé rire dans la partie suivante des mé anismesde gestion de le d'attente quipourront êtreutilisés pour
mettre en ÷uvre une politiqued'élimination séle tive né essaire au omportement assuré du modèleDiServ.
Drop Tail : DT
La gestion de le utilisée par défaut au sein des routeurs est : Drop Tail Les paquets sont mis dansla le de sortie et servisdans l'ordre ave lequel ils ont été reçus par le ou les interfa es d'entrée. C'est aussila dis iplinela moins oûteuse en termes de traitement par le routeur. Cette te hnique est su sante dans un réseau à forte apa ité ar nous pouvons onsidérerqueles les restant presquetoujoursvides, lesdélaissontalors faibles, voire insigni ants. Par ontre, dans le asd'une rafale, la le d'attente peut se retrouver en débordement et les paquets arrivés après la rafale peuvent être jetés. Dans e as, les paquetsjetéslesontdemanièreindiéren iée,sanspriseen omptedutypedetra auquel ils orrespondent.En utilisantdesstratégies demiseen led'attente diéren iée, onpeut permettreà ertainstypesde tra d'êtreprivilégiésen détruisant ertainspaquetsplut t que d'autres.
Random Early Dete tion : RED
Ce mé anisme a tif de gestion de le d'attente (AQM 2
) a pour obje tif d'anti iper la ongestion avant que ette dernièrene seproduise.Pour sefaire,ilva :
soit jeter aléatoirement des paquets par mesure préventive a n que TCP réduise sa transmission;
soitutiliserle ag ECN 3
[RFB01℄pour indiqueràTCP queles paquetsont traversé un noeud en voiede ongestion.
Le seuilàpartir duquelon ommen eà jeterles paquets,ainsiquele tauxde remplissage de la le,doiventêtre on gurés parl'administrateur. Dansun routeur, elareviendrait à mesurer letauxd'o upation de lamémoire.
Sa fon tion d'élimination est basée sur la taille moyenne de la le, e qui autorise des u tuations instantanées né essaires pour le traitement du tra très variable. Dans sa dé nition [FJ93 ℄, RED n'impose au une formule pour le al ul de l'o upation moyenne. Par ontre, dansles exemples,un ltre passe basestutilisé omme lemontrel'algorithme de la gure3.8.
Ave q : l'o upation instantanée de la le et Wq le poids attribué à haque nouvelle mesure. Il faut remarquer quele ode prend en ompte les périodespendant lesquelles la le est ina tive, supposant que m paquets de taille minimale auraient pu être transmis pendant e temps-là.
Toujours basé sur la moyenne (avg), RED utilise une fon tion aléatoire roissante pour dé ider siun paquet doit être éliminé. Grâ eà ette ara téristique, les éliminations su - essives sont évitées. Le rejet de plusieurs paquets appartenant à une même rafale peut for erun uxTCPàrentrerdanslaphasedeslowstart.Lerejetaléatoireestunesolution
2
A tiveQueueManagement 3
Initialisation: avg = 0
A l'arrivée de haque paquet : SI la file n'est pas vide
avg = (1 - Wq)avg + Wq q SINON
m = temps pendant lequel la file était vide m
avg = (1 - Wq) avg
Fig.3.8 Cal uldel'o upationmoyennedela ledansRED
équitable puisque la probabilité pour qu'un ux subisse une perte est dire tement pro-portionnelle au pour entaged'o upation de e ux dansla le. DansRED, l'élimination aléatoire se réalise uniquement lorsque la taille moyenne de la le se trouve entre deux seuilsthmin et thmax omme lemontre l'algorithmede la gure3.9
SI thmin <= avg <= thmax ount = ount + 1
Pb = Pmax(avg - thmin)/(thmax - thmin) Pa = Pb / (1 - ount * Pb) ave probabilité Pa : éliminer le paquet ount = 0 SI thmax <= avg éliminer le paquet ount = 0
Fig.3.9 Cal uldel'o upationmoyennedela ledansRED
La variable ount ompte les paquets a eptés dansla ledepuis la dernière élimination. Cettevariableréduit onsidérablementlerisqued'éliminerdeuxpaquets onsé utifs.Dans le ode, Pa représente la probabilité de rejet du paquet. Elleaugmente linéairement de0 àPmaxpendant quelamoyenne variedethminàthmax omme lemontrela gure3.10. A partir de thmax, tous les paquets sont éliminés. Si les sour es réduisent leur débit en onséquen e,lamoyenne revient rapidement à unniveau a eptable.
Le mode de fon tionnement de RED a été utilisé dans la on eption d'autres méthodes visant à améliorer la performan e de TCP, en parti ulier le drapeau ECN. Ave ette méthode une sour e TCP est informéede la ongestion grâ eà un drapeau dansl'en-tête IP. Dans e as, RED n'élimine pas les paquets, il se ontente d'a tiver le drapeau pour indiquer quele débit doitêtre réduit. Le ré epteurdu paquet TCP re ète la valeur de e drapeau dans les a quittements pour que la sour e réagisse à ette demande. L'ECN est
th max
th min
1
Pmax
avg
Pa
Fig. 3.10REDPa
avg
th max−out
th min−in
th min−out
th max−in
1
P max_out
P max_in
Fig. 3.11RIO [BCC +98 ℄ re ommande l'installation sur les routeursdu mé anisme RED et la dé nition de mé anisme de gestion des ux non régulés. Le ouplage de l'algorithme RED à un mé anisme de gestion de priorité du type de elui dé ni dans DiServ pour le hoix des datagrammes àéliminer estévoqué.
Random Early Dete tion IN OUT : RIO
RIOestl'undespremiersalgorithmesàavoirétéproposépouree tuerunediéren iation de servi es. Dans [CF98 ℄, il est dé rit toute une ar hite ture qui a servi de référen e aux travauxde l'IETF.A l'origine,RIOétait onçu pour faire deladiéren iation entredeux niveaux de priorité à la perte (IN et OUT). A tuellement, le modèle a été étendu pour supporter plusieurs niveaux. Dans RIO, la diéren iation se base en partie sur le al ul de l'o upation moyenne de la le. A la diéren e de WRED, l'algorithme al ule une moyenneparprioritéàlaperte(droppre eden e).Lamoyenneavg
n
esta tualiséeà haque fois qu'un paquet depriorité à laperte égale ou inférieure à n arrive dans la le. Pour le as de DiServ, avg re ète lamoyenne des paquetsde basse priorité à la perte présents
th min−out
th max−out
th min−in
th max−in
1
avg
Fig. 3.12PBSdans la le; avg 1
, la somme des paquets de priorité à la perte basse et moyenne; en n, avg
2
, ommedansRED,prenden onsidérationtouslespaquetsquiattendentdansla le. Ce ipermet d'isoler laprobabilité derejet pour haqueniveau.Pour les paquetsdebasse priorité à la perte, seul un ex ès de paquets de la même priorité à la perte justi e une élimination.Pour les paquetsde hautepriorité à laperte, l'ex ès depaquets de prioritéà lapertemoinsfortesu tpourqu'ilssesoientrejetés.[CF98 ℄proposent aussid'utiliserdes paramètres RED (pmax, thmin et thmax) diérents pour haque niveau. La gure 3.11 illustrelamiseenpla ede esseuils.Desvaleurssimilairesà ellesquiseraientutiliséesdans WREDpourraient êtreutilisées.Le al uldiéren iédesmoyennesajoutéauparamétrage deREDfont deRIOunalgorithmetrèsperformantpourl'élimination baséesurlapriorité àla perte.
Weighted Random Early Dete tion : WRED
Même te hnique que la pré édente mais qui permet de déterminer quel tra on jette grâ eàlapriseen ompte du hampIPPre eden e parles routeurset elaa nd'éviterla monopolisation desressour es par ertaines lasses de tra . Cette pondérationgérée via e hamppermet auréseaude demander aux uxdetra moinsprioritairesdes'adapter aupro t dutra plusprioritaire. L'algorithme WREDest expliquédans[Sys01℄.
Partial Buer Sharing: PBS
La lePBS[PF91 ℄, dont leprin ipedeseuilestillustré gure3.12estun asparti ulierde on gurationdela leRIO.Desétudes ontmontré quelapolitiquedegestiondel'attente RED introduit de l'instabilité et des os illations [BMB00 , ZFH99℄. Cette solution repose surunepolitiquedéterministemiseen÷uvreparunmé anismeàsimpleseuil.Lespaquets opportunistessontsystématiquement rejetésdèsquelenombretotaldepaquetsenattente dansla leex ède un ertainseuil.
Push Out : PO
A l'opposédesmé anismes àseuil, lemé anisme PushOut [HG90℄éje te les paquetsnon prioritairesqu'unefoisla led'attente pleine.Dans e as, lesnouveauxpaquetsnon prio-ritairessont immédiatement rejetéstandisque lesnouveaux paquetsprioritairesprennent lapla edespaquetsnonprioritairesdéjàprésentsdansla le.Lespaquetsprioritairessont alors rejetéslorsquela apa itémaximaledela led'attenteestatteinteet qu'au unautre paquet non prioritaire estprésent dansla le.
3.4 CONCLUSION DU CHAPITRE
Nous avons dé rit dans e hapitre les mé anismes réalisant des a tions né essaires au supportde laqualité deservi edansleréseau. Toutd'abord,l'identi ation etla ara té-risation d'un ot va permettre de déterminer la onformité de e dernier vis-à-vis de son ontrat de servi e. Puis, la mise en pla e des mé anismes de gestion de le d'attente et d'ordonnan ement va tenter de satisfaire les besoins de qualité de servi e requise par le ot.La miseenpla e, la on gurationainsiquelesintera tions de esmé anismesdansle réseau dé nissent unmodèle dequalité deservi e.Danslemodèle IntServ,la on gu-ration de es mé anismes est faite dynamiquement à partir des ontraintes de qualité de servi equeles otsvontsignaler.En oreunproblèmederésistan eaufa teurd'é helle.Au ontraire, le modèle DiServdé nit une on guration statiquede es mé anismes faisant suite à une identi ation plus généraledesbesoinsen qualité de servi e.C'est à partir de e modèle quenousallonsproposer l'ar hite ture développéedans le hapitre suivant.
Mise en ÷uvre d'une
ar hite ture DiServ : Projet AIRS
4.1 INTRODUCTION
Nous allons dé rire dans e hapitre la mise en ÷uvre d'un domaine DiServ réalisée au sein du projet irs
1
. Nous détaillerons plus parti ulièrement la stru ture interne d'un routeurde ÷ur etd'un routeur de borduregérantlaqualité deservi e. Tout d'abord, un développement basésurlapile IPv6Musi aIPaétéee tuéa nd'in lurelesmé anismes de qualité de servi e hoisis pour le projet. En n, une interfa e utilisatri e, permettant de piloter es modules, aété développée. La syntaxe des ommandes est inspirée du ode ADServ[Med00 ℄développépour l'interfa e ALTQ [Cho99 ℄.
4.2 PARTICULARITÉS MATÉRIELLES ET LOGICIELLES DE LA
PLATEFORME
Le premier point marquant du projet est l'utilisation du proto ole IPv6 en lieu et pla e de la version IPv4, e i a n de béné ier des nombreuses évolutions asso iées : apa ité d'adressage, de routage, de on guration automatique, d'identi ation de ots, ... A n de privilégier une portabilité maximum des développements ee tués, une sou he IPv6 ommune auxdeuxsystèmes utilisés(FreeBSDet Windows NT) aété hoisie. Il s'agitde Musi aIP développée par laso iété6WIND. Latotalité destravaux réalisésreposant sur ette sou he, nousladétaillerons plus pré isément,et nousverrons en quoi ette dernière a in ué la mise en ÷uvre de notre ar hite ture. Au niveau de la plateforme matérielle mise en pla e au LIP6, on trouve latotalité des ma hines impliquéesdans les diérentes expérimentations :
ommutateur ATMreliéà Renater2; 1
