2002 - 2003

Etude du service DiffServ

Sylvain FRANCOIS Anne-Lise RENARD Jrmy ROVARIS

SOMMAIRE

INTRODUCTION................................................................................................................3 1 QUALITE DE SERVICE..................................................................................................4 2 DIFFERENCIATION DE SERVICES : ..........................................................................6 2.1 PRESENTATION ..............................................................................................................6 2.2 LES CLASSES DE SERVICES .............................................................................................7 2.2.1 Le Best Effort.........................................................................................................7 2.2.2 Expedited Forwarding ...........................................................................................7 2.2.3 Assured Forwarding ..............................................................................................8 3 ARCHITECTURE DIFFSERV ...................................................................................... 12 3.1 PRESENTATION ............................................................................................................ 12 3.2 CLASSIFICATION ET CONDITIONNEMENT DU TRAFIC ...................................................... 13 4 INTEGRATION AVEC DAUTRES SERVICES ......................................................... 15 4.1 INTEGRATION INTSERV/DIFFSERV ............................................................................... 15 4.2 INTEGRATION MPLS/DIFFSERV ................................................................................... 15 5 MISE EN UVRE DE DIFFSERV ............................................................................... 16 5.1 PRINCIPE ..................................................................................................................... 16 5.2 EXEMPLES DE SCENARII POSSIBLES :............................................................................. 17 Scnario 1 .................................................................................................................... 17 Scnario 2 .................................................................................................................... 17 Scenario 3 .................................................................................................................... 17 Scnario 4 .................................................................................................................... 17 Scnario 5 .................................................................................................................... 17 Scnario 6 : trafic audio et FTP ................................................................................... 18

Introduction
ses dbuts, Internet avait pour seul objectif de transmettre les paquets leur destination. Conu pour le transport asynchrone des donnes, IP (Internet Protocol) n'a pas t prvu pour les applications en temps rel comme la tlphonie ou la vido, trs contraignantes. Le besoin en quipements de plus en plus fiables, d'un bout l'autre du rseau, est donc devenu incontournable. Cependant, les dfauts rencontrs sur les rseaux (perte de paquets, congestion) ne peuvent pas tre surmonts sans une rnovation profonde de l'architecture. La qualit de service est la mthode permettant de garantir un trafic de donnes, quelle que soit sa nature, les meilleures conditions d'acheminement rpondant des exigences prdfinies. Elles fixent notamment des rgles de priorit entre les diffrents flux. La matrise de la qualit de service est un enjeu essentiel. La qualit de service 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 au besoin de lentreprise.

1 Qualit de service
LInternet, comme la majorit des rseaux en mode paquets, na pas t initialement prvu pour prendre en compte les paramtres de qualit de service. Les rseaux en mode paquets ont t dvelopps une poque o la bande passante tait rare, la stratgie tant doccuper le maximum de liens quitte introduire des dlais supplmentaires dans la transmission des donnes. Les oprateurs et quipementiers se sont donc attels une double tche : mettre en place de nouveaux mcanismes pour s'assurer de la disponibilit des applications c'est--dire contrler le nombre de paquets perdus - tout en ne reniant pas les principes fondamentaux d'Internet, savoir sa simplicit, sa fiabilit et son universalit. Voil donc tout l'enjeu de la qualit de service, ou QoS. Il y a quatre paramtres techniques prendre en compte dans la qualit de service qui sont : - la disponibilit du rseau - le temps de rponse - le dbit garanti par flux - la stabilit des paramtres prcdents Les paramtres de services ou de prestations sont quant eux nombreux, on peut citer les plus importants : - la disponibilit de service (SVP, guichet unique) - le point central de prise en compte des problmes (guichet unique) - le temps de traitement dun incident ou dune demande - le support technique du prestataire - Afin de garantir cette qualit de service, trois protocoles se sont imposs : - Intserv (Integrated Service, protocole inclus dans RSVP, Ressource Reservation Protocol) - Diffserv (Differentiated Services) - MPLS (MultiProtocol Label Switching) Leur standardisation est effectue par l'IETF (Internet Engineering Task Force). Intserv repose sur un mcanisme de rservation des ressources. Dans la pratique, il ddie une partie de la bande passante pour assurer l'acheminement des messages prioritaires. Trs complexe mettre en oeuvre, Intserv convient plutt aux rseaux de petite taille, mais n'est pas vraiment adapt Internet dans son ensemble. De ce fait, il a t peu dploy. Pour pallier ces carences, l'IETF a adopt un second modle, Diffserv, qui assure une distinction des paquets par classes de flux. Les donnes sont identifies grce un marquage dans le champ ToS (Type of Service, champ spcifique rserv dans l'entte IP de 8 bits), qui fixe les priorits. Chaque nud du rseau apporte un traitement diffrenci en fonction de la classe de service du paquet. Mais l'arrive de MPLS a chang la donne. Cette nouvelle architecture permet de vhiculer davantage de trafic IP des vitesses de transmission trs leves. Dans ce cas, les paquets transfrs sont directement tiquets (label de 32 bits) l'entre du rseau, spcifiant leur chemin, ce qui vite au routeur de chercher l'adresse laquelle le paquet doit tre envoy. MPLS s'appuie sur les classes de service Diffserv et fonctionne avec 4

tout protocole existant - IP, bien sr, mais aussi ATM et Frame Relay -, ce qui en fait un protocole de choix, car les rseaux transportent de plus en plus de paquets issus de diverses plates-formes. Une bonne qualit de service sur les rseaux actuels suppose une implantation correcte de deux fonctions : performance garantie et politiques de routage. Les politiques de routage sont utilises pour affecter des ressources en priorit aux applications, aux groupes de travail ou aux serveurs. Avec l'augmentation constante du volume de trafic sur les rseaux, les garanties de performance sont obtenues en contrlant la bande passante en fonction des politiques de routage. Lvolution dInternet pour prendre en compte les nouveaux flux se fait en modifiant les mcanismes de files dattente dans les routeurs. Une solution : introduction dun contrle daccs pour limiter le trafic dans le rseau. Si la capacit de celui-ci en terme de bande passante est infrieure la demande de transmission, le taux de perte augmente rapidement dans un rseau. Une solution pour limiter ce taux de perte est de limiter la demande de transmission en mettant en place un contrle dadmission en entre du rseau. Cette solution est utilise dans le rseau tlphonique et ATM. Il est difficile mettre en uvre dans lInternet car lchange dinformation entre systmes ne porte que sur des informations de routage. Une deuxime solution : sparer les flux ayant des contraintes du trafic BestEffort et de protger ces flux dans les routeurs pour obtenir des garanties de dbit, de dlai et de taux de perte. Cette approche ncessite de rserver des ressources dans le rseau pour ces flux. Une troisime solution : ne donner aux flux plus sensibles quune priorit plus importante, ce qui ne permet pas de garanties strictes des performances. Une quatrime solution : sur-dimensionnement du rseau pour viter la pnurie de bande passante, mais cela pose des problmes de communication malgr lutilisation de la fibre optique.

2 Diffrenciation de services
2.1 Prsentation
La diffrenciation de services consiste dans une situation de congestion reporter les pertes de paquets sur certaines classes de trafic, pour en protger dautres. Il ny a donc pas de garantie sur les flux car il ny a pas de contrle dadmission dynamique permettant dviter une congestion. Le contrle dadmission est fait a priori par la dfinition dun contrat pour chaque classe de trafic et par le dimensionnement des ressources pour pouvoir garantir ce contrat. Les paquets DiffServ sont marqus l'entre du rseau et les routeurs dcident en fonction de cette tiquette de la file d'attente dans laquelle les paquets vont tre placs. Cette architecture convient des rseaux pour lesquels il n'est pas raisonnable d'envisager une signalisation flux par flux. Elle ne considre donc que des agrgats de flux pour lesquels une signalisation avec rservation de ressources peut-tre envisage. En fait un routeur de cur ne conserve pas d'tat pour un flux ou un agrgat donn, mais traite tous les paquets d'une classe donne de la mme manire. Les donnes sont identifies grce un marquage dans le champ ToS (Type of Service, champ spcifique rserv dans l'en-tte IP de 8 bits), qui fixe les priorits. Cette zone se dcompose en un premier champ de trois bits baptis " IP Precedence ", qui prcise le niveau de priorit appliqu au paquet. Vient ensuite un champ de 4 bits, dont la valeur dtermine un critre de routage. Le dernier bit du champ reste inutilis. Cette classification s'opre l'entre du rseau tendu, dchargeant ainsi les routeurs de la tche. La diffrenciation de services prsente les avantages suivants : La signalisation est faite dans chaque paquet en attribuant une signification diffrente aux bits du champ type de service. Il nest plus besoin de garder dans le routeur un contexte liant le flux de signalisation au flux de donnes. Cela permet aussi une agrgation naturelle des flux, ainsi pour un oprateur, les paquets quil reoit marqus pour une certaine classe peuvent appartenir plusieurs sources. La complexit du traitement est concentre dans les routeurs aux frontires du rseau. Ils effectuent les oprations complexes de contrle de la validit du contrat pour les diffrentes classes de trafic. Dans le cur du rseau, le traitement est plus simple, ce qui autorise un relayage rapide des donnes. La tarification du service est plus simple, il suffit de dfinir les paramtres de contrles de classes de service.

Au contraire du modle Intserv qui traite indpendamment chaque flot, le modle Diffserv spare le trafic par classes. Nous avons donc affaire une granularit moins fine mais qui devient en revanche plus scalable . En effet, la granularit du flot implique la raction en chane suivante : plus il y a d'utilisateurs dans le rseau, plus il y a de flots, plus il y a de variables de classification et d'ordonnancement dans les routeurs maintenir, ce qui a pour consquence une charge importante au niveau des routeurs qui deviennent alors de moins en moins performants. Les routeurs DiffServ traitent les paquets en fonction de la classe code dans l'entte IP (champ DS) selon un comportement spcifique : le PHB (Per Hop Behaviour). Chaque ensemble de paquets dfini par une classe reoit alors un mme traitement et

chaque classe est code par un DSCP (DiffServ Code Point). Un PHB est dfini par les priorits quil a sur les ressources par rapport dautres PHB. En aucun cas, les routeurs ne traiteront diffremment des paquets de mme PHB et de sources diffrentes. L'avantage de Diffserv est qu'il n'y a plus ncessit de maintenir un tat des sources et des destinations dans les routeurs, d'o une meilleure scalability. Diffserv dfinit quatre PHB ou classes de service : - Best Effort (priorit basse) : PHB par dfaut et dont le DSCP vaut 000000 ; - Assured Forwarding (AF) (RFC 2597) : regroupant plusieurs PHB garantissant un acheminement de paquets IP avec une haute probabilit sans tenir compte des dlais, cette famille de PHB est scinde en 4 classes garantissant de fournir une bande passante et un dlai minimum, chaque classe comprenant 3 niveaux de priorit (Drop Precedence) ; - Expedited Forwarding (EF) ou Premium Service (RFC 2598) : correspondant la priorit maximale et a pour but de garantir une bande passante avec des taux de perte, de dlai et de gigue faible en ralisant le transfert de flux fortes contraintes temporelles comme la tlphonie sur IP par exemple ; - Default Forwarding (DF), utilis uniquement pour les flux Internet qui ne ncessitent pas un trafic en temps rel. Cette notion de PHB permet de construire une varit de services diffrencis. Les PHB sont mis en oeuvre par les constructeurs dans les routeurs en utilisant des mcanismes de gestion de files d'attente (Custom Queuing, Weighted Fair Queuing, ...) et de rgulation de flux.

2.2 Les Classes de service

2.2.1 Best Effort Le principe du Best Effort se traduit par une simplification lextrme des quipements dinterconnexion. Quand la mmoire dun routeur est sature, les paquets sont rejets. Le principe de bout en bout de lInternet est aussi adopt pour le contrle de flux grce diffrents algorithmes comme le Congestion Avoidance introduit dans TCP. Les principaux inconvnients de cette politique de contrle de flux sont un trafic en dents de scie compos de phases o le dbit augmente puis est rduit brutalement et une absence de garantie long terme.

2.2.2 Expedited Forwarding La classe Expedited Forwarding correspond la valeur 101110 pour le DSCP et l'objectif est de fournir un service de transfert quivalent une ligne virtuelle ddie travers le rseau dun oprateur. Le contrat porte sur un dbit constant. Les paquets excdentaires sont lisss ou rejets lentre pour toujours rester conforme au contrat. Loprateur sengage traiter ce trafic prioritairement. Pour que le service soit performant, il faut quil ne prsente quune faible partie du trafic total pour quaucun paquet marqu EF ne soit rejet dans le cur du rseau.

Pour atteindre ces performances, les paquets dun service EF ne devraient pas subir de file dattente ou passer par des files de trs petite taille et strictement prioritaires. De plus, les flux ne doivent avoir que trs peu de perte, la gigue doit tre minimale et la bande passante garantie. Dune part, cela ncessite la mise en place dun contrle daccs et, dautre part, cela impose qu chaque nud travers, le taux maximal de trafic darrive doit tre infrieur au taux minimal de trafic de dpart. Cette dernire assertion implique que, dans les nuds internes, une bande passante minimale est disponible au service EF et que, dans les nuds dextrmit, un traffic conditioning est effectu. Ce mcanisme de conditionnement est utilis pour vrifier la conformit des flux utilisateurs. La conformit du trafic EF et AF par rapport leurs profils est dtermine pour chacun par un token bucket (cf. page 11). Dans ce cas, la taille et le dbit du bucket sont spcifier. Les paquets EF non conformes sont dtruits tandis que les paquets AF non conformes sont marqus pour tre jets en cas de congestion. Ainsi, il faut choisir parmi toutes les possibilits que DiffServ offre, cest--dire celles qui rpondent le mieux aux besoins du service. On s'intresse d'abord au choix du PHB, le paramtre qui dfinit le comportement des routeurs de cur du rseau. Par exemple pour les streams multimdia, tant donnes leurs caractristiques, le comportement de EF n'est pas adapt. EF est un comportement coteux, en particulier cause des garanties de dlai qu'il peut offrir. Pour le streaming, les variations de dlai sont normalement absorbes par un buffer chez le rcepteur, les assurances de dlai ne sont donc plus indispensables. Plus important encore, dans EF la notion de priorit dans les paquets n'existe pas alors que c'est un lment cl du service que l'on cherche proposer. AF quant lui, rpond au besoin d'attribuer des priorits aux paquets en offrant trois niveaux de priorit. De plus, l'existence de 4 classes diffrentes permet de rsoudre facilement le problme de partage de ressources entre les flux UDP et TCP. En rservant une classe AF au trafic UDP et une autre au trafic TCP, les deux types de flux seront isols par l'algorithme d'ordonnancement dans les routeurs (WFQ, CBQ, etc.) ce qui permet d'viter la concurrence directe entre eux. Nous proposons donc, l'utilisation de la classe AF rserve pour les flux Audio/Vido.

2.2.3 Assured Forwarding La classe Assured Forwarding dfinit 3 priorits dfinissant lordre de rejet dans un routeur en cas de congestion. Les priorits sont reprsentes par 3 couleurs qui dpendent de la conformit de la source avec son contrat. Le marqueur utilis actuellement est bas sur deux token buckets : si le trafic est conforme au deux, les paquets sont marqus en vert, sil nest conforme qu un des deux les paquets seront marqus en orange et sils ne sont conformes aucun, ils seront marqus en rouge. Les paquets marqus en rouge, ont une probabilit de rejet plus importante que les oranges. Dans le cur du rseau, les mcanismes de rejet sont bass sur RIO (cf. page 11). Chaque couleur dispose dun seuil et dune probabilit de rejet diffrent. Quatre classes AF sont disponibles. Il ny a pas de priorit parmi ces classes.

Figure 1 : arrive des paquets dans un edge router puis dans un core router

Les travaux du groupe Diffserv sont surtout bass sur une approche dingnierie portant sur la dfinition de larchitecture et sur la gestion de loctet DS. Les rsultats de simulation montrent que RIO est trs sensible aux conditions initiales du trafic, en particulier, la proportion de trafic UDP influe normment sur les rsultats. Les objectifs de la diffrenciation par lAssured Forwarding sont lattribution diffrentie des ressources et la protection des flux TCP des flux UDP. Pour lAssured Forwarding, il est dfini quatre classes de service et trois priorits (appeles niveaux de post prcdence) suivant que l'utilisateur respecte son contrat, le dpasse lgrement ou est largement en dehors. Les classes sont donc choisies par l'utilisateur et restent les mmes tout au long du trajet dans le rseau. Tous les paquets dun mme flux appartiennent la mme classe. A lintrieur de chaque classe, un algorithme de rejet slectif diffrencie entre 3 niveaux de priorit. En cas de congestion dans une des classes AF, les paquets de basse priorit sont rejets en premier. La priorit peut tre modifie dans le rseau par les oprateurs en fonction du respect ou non des contrats. AF offre diffrents niveaux de services : AF1 (AF11, AF12, AF13) AF2 (AF21, AF22, AF23) AF3 (AF31, AF32, AF33) AF4 (AF41, AF42, AF43)

Avantages de lAssured Forwarding : peut offrir une meilleure diffrenciation (classe et priorit) le marquage lentre du rseau est une opration moins coteuse que le shaping ne demande pas une coordination entre domaines une facturation simple peut tre utilise. Inconvnients de lAssured Forwarding : la qualit offerte dpend normment du niveau dagrgation et de la prsence de flux concurrents il nexiste aucune assurance de dlai il y a beaucoup de paramtres rgler 3 niveaux de priorit ne suffissent pas pour assurer une bonne diffrentiation sur des liens non-chargs un mauvais dimensionnement rend inutile la prsence de priorits sur des liens en congestion le marquage ne suffit pas pour protger TCP de UDP. Pour obtenir une bonne diffrenciation avec lAssured Forwarding, il faut : un regroupement des flux similaires dans une mme classe des mcanismes de marquage adapts des variations du dbit, rafales, etc. un marquage en fonction du rsultat que lon veut obtenir.

Une classe PHB

AF Class 1: AF Class 2: AF Class 3: AF Class 4:

30% Bande passante 20% Bande passante 10% Bande passante 5% Bande passante

Exemple : AF12 = (Classe AF 1, Drop = 2) => DSCP = Low Drop Prec Medium Drop Prec High Drop Prec

dd= drop precedence

Class AF1 Class AF2 Class AF3 Class AF4

001010 010010 011010 100010 001100 010100 011100 100100 001110 010110 011110 100110

10

Rappel sur le principe du Token Bucket : lalgorithme Token Bucket est un algorithme de lissage de trafic. Des jetons sont accumuls dans un seau, de taille finie, dbit constant. Lorsque les paquets passent, ils dcrmentent le nombre de jetons du seau. Les paquets passent donc vitesse leve tant quil reste des jetons. Ensuite, ils passent au dbit de remplissage du seau.

Rappel sur le RED : Random Early Detection (RED) est un mcanisme qui prend les avantages des mcanismes de contrle de congestion de TCP. En priode de congestion, on attribue des priorits aux paquets. RED dit la source des paquets de diminuer le taux de transmission. La source diminuera alors son dbit jusqu ce que tous les paquets atteignent nouveau leur destination, ce qui indique quil ny a plus de congestion. RED peut aussi rejeter certains paquets avant que le buffer ne soit compltement plein, cela vite ainsi de dtruire un trop grand nombre de paquets.

Rappel sur le WRED : Weighted RED (WRED) gnralement base sur la prcdence IP. Les paquets avec une prcdence IP leve ont moins de chance dtre jets que ceux avec un taux faible. Ainsi, le trafic de plus haute priorit sera dlivr avec une probabilit plus grande que le trafic de faible priorit. Il est trs utile sur les interfaces de sortie o il peut y avoir de la congestion. Il est gnralement utilis dans les routeurs de cur de rseau plutt que ceux de bordure. En effet se sont les routeurs de bordure qui affectent la prcdence IP aux paquets alors que WRED sen sert pour dterminer le comportement avoir.

Rappel sur RIO : RIO permet d'implanter une classe Assured Forwarding (AF) qui a t dfinie par l'IETF. Plus prcisment, les paquets sont marqus In ou Out l'entre du rseau (on utilise pour cela un token bucket) selon leur degr de priorit ; en cas de congestion les paquets Out sont rejets en premier, puis les paquets In le sont leur tour ds lors que la congestion s'amplifie.

11

3 Architecture Diffserv
3.1 Prsentation
Le groupe Diffserv propose donc d'abandonner le traitement du trafic sous forme de flots pour le caractriser sous forme de classes. Le [RFC2475] prfre dailleurs le terme de behaviour aggregate (BA) plutt que de classe de trafic. Le service diffrenci de larchitecture Diffserv permet de diminuer les informations dtat que chaque nud du rseau doit mmoriser. Il nest plus ncessaire de maintenir des tats dans les routeurs pour chacun des flux. Ceci permet son utilisation grande chelle. Lide consiste diviser le rseau en domaines. On distingue ainsi les routeurs lintrieur dun domaine (Core router) des routeurs daccs et 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. Les routeurs de bordure jouent un rle diffrent de ceux qui sont au cur du domaine. Ils sont chargs de conditionner le trafic entrant en indiquant explicitement sur le paquet le service quil doit subir. Ainsi, la complexit des routeurs ne dpend plus du nombre de flux qui passent mais du nombre de classes de service. Chaque classe est identifie par une valeur code dans l'en-tte IP. Le trafic conditionn est identifi par un champ DS ou un marquage du champ Type of Service (ToS) de l'en-tte de paquet IPv4 ou loctet Class Of Service (COS) dIPv6. Ce champ dentte IP porte lindice de la Classe de Service DSCP (Differentiated service Code Point). Sachant que ce travail de marquage est assez complexe et coteux en temps de calcul, il vaut mieux limiter au maximum les rptitions. Les oprations de classification, contrle et marquage sont effectues par les routeurs priphriques (Edge Router) tandis que les routeurs centraux (Core Router) traitent les paquets en fonction de la classe code dans l'en-tte d'IP (champ DS) selon un comportement spcifique : le PHB (Per Hop Behavior) cod par le DSCP. Rappel sur le principe du DSCP : cest le champ qui identifie le traitement que le paquet doit recevoir. Ce champ est cod sur 6 bits et fait parti des 8 bits codant le champ TOS dIPv4 ou le champ classe de trafic dIPv6.

DSCP : Differentiated Service Code Point (6bits) CU : Currently Unused ( 2bits) Pour la classe EF DSCP = 101110 Pour la classe AF DSCP = 12 codes (cf. prcdemment)

12

L'architecture des services diffrencis propose dans le [RFC2475] contient deux types d'lments fonctionnels : Les lments de bordures (edge functions) : ils sont responsables de la classification des paquets et du conditionnement du trafic. En bordure du rseau, c'est dire l'arrive du premier lment actif capable de traiter le champs DS (DS-capable), les paquets arrivant ont dans leur champ TOS (pour IPv4) ou Traffic Class Octet (pour IPv6), une certaine valeur DS. La marque qu'un paquet reoit identifie la classe de trafic auquel il appartient. Aprs son marquage, le paquet est envoy dans le rseau ou jet. Les lments du cur du rseau (core functions) : ils sont responsables de l'envoi uniquement. Quand un paquet, marqu de son champ DS, arrive sur un routeur DS-capable, celui-ci est envoy au prochain nud selon ce que l'on appelle son Per Hop Behaviour (PHB) associ la classe du paquet. Le PHB influence la faon dont les buffers du routeur et le lien sont partags parmi les diffrentes classes de trafic. Une chose importante dans l'architecture DS est que les PHB routeurs se basent uniquement sur le marquage de paquet, c'est dire la classe de trafic auquel le paquet appartient ; en aucun cas ils ne traiteront diffremment des paquets de sources diffrentes.

Dans larchitecture Diffserv, le traitement diffrenci des paquets sappuie sur 3 oprations fondamentales : - la classification des flux en classes de services - lintroduction de priorits au sein des classes (Scheduling) - et la gestion du trafic dans une classe donne (Queue management). La deuxime opration est assure par les algorithmes dordonnancement servant contrler la distribution de ressources entre les classes de service. On peut donner en exemple 2 types dordonnanceurs : PQ (Priority Queueing) et WRR (Weighted Round Robin). Le modle PQ utilise plusieurs files dattente logiques. Les paquets classifis sont mis dans une file dattente correspondant la valeur du DSCP. Les files sont ensuite servies suivant un algorithme spcifique. Celle qui contient les paquets avec la plus haute priorit sera favorise par rapport aux autres files. Le modle WRR utilise aussi plusieurs files dattentes mais qui sont servies tour de rle. A chaque tour, on transmet un nombre de bits (ou de paquets) correspondant au poids de la file.

3.2 Classification et conditionnement du trafic

La classification s'effectue suivant une ou plusieurs valeurs contenues dans l'entte IP (exemple : adresse source - destination, port source - destination, protocol ID, ...). Celle-ci faite, elle dirige le paquet vers la fonction de marquage approprie comme le montre la figure :

13

Figure 2 : arrive des paquets dans un edge router Une fois les paquets marqus, ils sont envoys leur destination puis chaque routeur DS-capable, ils reoivent le service associ leur classe. Il n'est pas prcis par le groupe de travail Diffserv comment le classificateur est paramtr pour effectuer cette classification ou plus exactement, qui le paramtre. Cela doit tre fait manuellement, aux bons soins de l'administrateur (qui paramtre les tables de marquage des paquets en fonction d'une table d'adresse source, par exemple, donne au edge router) ou par le biais d'un protocole de signalisation ; RSVP pourrait d'ailleurs trs bien faire l'affaire, en effet, celui-ci n'tant pas un protocole de signalisation propre Intserv uniquement, on pourrait l'utiliser afin de signaler les classes que les routeurs auront traiter. En plus de cette classification (ou marquage), un mcanisme de profilage du trafic est dfini par le groupe de travail Diffserv. Ce traffic profile a pour objet la prise en compte du taux d'arrive des paquets, afin de ne pas dpasser le seuil maximum de paquets pouvant tre envoys sur le rseau. Ainsi, un mcanisme de mesure du trafic permet de savoir si le flot de paquets entrants correspond au profil de trafic ngoci. Si ce flot dpasse un certain seuil, certains paquets seront marqus comme moins prioritaires et seront automatiquement jets en cas de congestion dans le rseau comme le montre la figure :

Figure 3 : classification, marquage et conditionnement du trafic au niveau du edge router

14

4 Intgration avec dautres services

4.1 Intgration IntServ/DiffServ
Lintgration de ces deux mcanismes est ltude. Plusieurs propositions ont t soumises. La premire solution consiste ne mettre lintgration de service que dans les sites terminaux. Le cur 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 lment de rseau et le caractriser pour permettre de construire un service garanti.

4.2 Intgration MPLS/DiffServ

MPLS permet de simplifier ladministration dun cur 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 et en rduisant la frquence. 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 label est attribu en fonction de la classe de relayage 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. Le label dcide donc dans chaque routeur du prochain routeur, du comportement DiffServ et de lutilisation ventuelle des ressources rserves.

15

5 Mise en uvre de DiffServ

5.1 Principe
Le trafic entrant dans le rseau est classifi et se voit attribu des ressources, en fonction des critres de gestion du modle de service. Aucune rservation n'est faite, mais un dimensionnement adquat assure qu'il aura assez de ressources dans le rseau pour les demandes de toutes les applications. Les garanties donnes par le modle vont dans le sens du partage des ressources disponibles. Pour offrir un certain niveau de QoS, les classifications donnent un traitement diffrentiel des applications senses d'avoir des besoins plus exigeants cest--dire des priorits. Une fois le mcanisme de priorit disponible, la mise en place d'une qualit de service suppose la dfinition des rgles pour utiliser ce mcanisme. Pour garantir le respect de ces rgles, on emploie une politique qui les impose aux limites d'un primtre. On parle de routing policies.

Figure 4 : classification, marquage et conditionnement du trafic Dans le cadre de la QoS, nous pourrions tenir compte de diffrents paramtres qui sont : le dlai, le dbit et le taux de perte de paquets. Cependant, ces paramtres sont difficiles mesurer du fait du caractre alatoire des pertes de paquets et du temps variable pass dans les files dattente sur tous les routeurs qui constituent le chemin entre une source et une destination. Il faut donc se limiter, dans le cas dune mise en uvre, aux paramtres tels que : le dlai, le taux de perte de paquets et la variation du dlai de bout en bout. Le dlai de bout en bout dtermine le temps que mettent les donnes pour tre achemine dune source une destination, il est compos dune partie constante : le temps de propagation et une partie variable qui tient compte du temps dattente dans les diffrentes mmoires tampons des routeurs traverss. La variation du dlai de bout en bout est due aux dlais dans les files dattente des routeurs. Le taux de perte de paquets est un facteur important car dans le cas dun taux trop lev, pour certain type dapplication, il est impossible de rmettre le paquet perdu. 16

5.2 Exemples de scnarii possibles

Figure 5 : un exemple de rseau de test

Scnario 1 Mettre en vidence la diffrence entre lutilisation de Differv et la non-utilisation de ce service. Pour cela on peut envoyer dans le rseau diffrents types de donnes, les unes aprs les autres puis toutes ensembles sur un mme chemin pour voir les problmes que cela peut entraner et comparer les rsultats obtenus en ritrant les transmissions mais avec le service Diffserv. Scnario 2 On peut considrer que lon a deux sources. Une qui envoie des fichiers de tests, par exemple des extraits vido, et lautre qui envoie un trafic continu pour simuler un vrai rseau utilis. Lenvoie de fichiers vido permet de voir la perte de paquets lors de la rception car dans le cas de problmes, limage sera brouille. On prend trois fichiers de mme type que lon envoie dans des conditions normales. Les rsultats serviront de tmoins. On envoie les trois mmes fichiers mais en appliquant Diffserv. On recommence mais on envoyant prcdemment un flux UDP pour crer une congestion sur un routeur de cur. Et enfin on envoie une dernire fois les trois fichiers on leur attribuant des priorits diffrentes puis des priorits identiques et fortes. Scenario 3 On pourrait faire la comparaison entre WRED et RIO. Scnario 4 On pourrait comparer la diffrence entre un flux UDP et un flux TCP en utilisant les programmes en C fait en 2me anne, avec linfluence pour le flux TCP des Token Bucket. Scnario 5 Voir linfluence dune agrgation en priphrie du rseau sur la QoS. Voir linfluence dune agrgation dans le cur du rseau sur la QoS.

17

Scnario 6 : trafic audio et FTP Cet exemple est tir dun document crit par Ibrahima NIANG et Dominique SERET Dimensionnement de DiffServ bas sur des mtriques de performances et donne un exemple complet dune ralisation de mise en uvre qui aurait pu tre faite. On peut grer 3 files dattentes de type : BE (Best Effort), EF et AF. Ces files dattentes doivent tre servies par des ordonnanceurs diffrents qui peuvent tre soit PQ (Priority Queuing) soit par WRR (Weighted Round Robin) qui ont t dfinis au chapitre prcdent. On peut considrer que dans le cas PQ, la file de la classe EF a la plus haute priorit et la file BE la plus basse. La file EF sera une simple FIFO et en cas de congestion, les paquets EF seront rejets. La file BE peut tre grer par un mcanisme RED (Random Early Detection) qui permet de prvenir les congestions avant quelles ninterviennent, en dtectant l avance le remplissage des buffers, sans attendre la saturation. Les paquets sont rejets par anticipation ce qui amne la source rduire son dbit. Un seuil de remplissage, infrieur au seuil de rejet par saturation, sert de dclencheur au mcanisme. La file AF pourra utiliser une extension du mcanisme prcdent appele RIO (RED In and Out). Ce mcanisme distingue le trafic In et Out. Dans ce cas, si un paquet est non conforme, il est marqu et sera dtruit en cas de congestion. Etant donn que les 2 classes les plus intressantes sont AF et EF, le scnario suivant sera bas sur ces 2 comportements. Le trafic audio est envoy dans la file de plus haute priorit EF et le trafic FTP dans la file de plus basse priorit AF.

Figure 6 : systme de file dattente des nuds DiffServ On envoie des paquets audio et FTPde taille connue. On fait les mesures.

18

Figure 7 : topologie simule

19

BIBLIOGRAPHIE Adresses Internet utilises pour raliser ce document : http://irl.cs.ucla.edu/twotier/ http://www-rp.lip6.fr/~lochin/qos/qoshtml/node8.html http://diffserv.sourceforge.net/ http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/mpls-arch/sld036.html http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/mpls-arch/sld037.html http://www-rp.lip6.fr/~lochin/qos/qoshtml/ http://www.loria.fr/~fleury/AlgoTel2000/Exposes/toutain/ http://wwwrp.lip6.fr/airs/Mise_en_oeuvre_et_etat_de_l_ar/mise_en_oeuvre_et_etat_de_l_ar.html http://www-sop.inria.fr/planete/intradiff/ http://www-rp.lip6.fr/~pan/enseignement/internet-multimedia/4-DEA1.pdf http://www.inria.fr/rrrt/rr-4511.html http://irl.cs.ucla.edu/twotier/ http://www.regit.org/article.php3?id_article=13 http://www.httr.ups-tlse.fr/pedagogie/cours/tcp-ip/diffserv/

20