RAPPORT DE PROJET DE FIN D’ETUDES                       Filière        Ingénieurs en Télécommunications                   ...
"Là où tout finira, là où tout commencera!"                                  Confucius
Remerciements        Je tiens tout d’abord à remercier Monsieur Rached Hamza (SupCom) pourmavoir fait lhonneur dêtre mon e...
Table des MatièresIntroduction Générale                                                                                   ...
Capitre III : Implémentation et simulation des fonctionnalités de MPLS TE                                                 ...
Table des figuresFigure 1.1 : Exemple dun réseau MPLS .......................................................................
Figure 3.16 : Gigue relatif au trafic HP .......................................................................49Figure 3...
AcronymesACK      acknowledgmentATM      Asynchronous Transfer ModeAToM     Any Transport over MPLSAWK      Aho, Weinberge...
PHOP      Previous HopPIM       Protocol Independent MulticastPPP       Point-to-Point ProtocolQoS       Quality of Servic...
Introduction générale                             Introduction Générale        La toile Internet connaît actuellement un d...
Introduction généraledégrader sa qualité. On peut ainsi passer outre la technique de commutation de circuit etutiliser la ...
Chapitre I : MultiProtocol Label Switching                                   Chapitre I :                          MultiPr...
Chapitre I : MultiProtocol Label Switching    •   LER (Label Edge Router) : cest un LSR qui fait linterface entre un domai...
Chapitre I : MultiProtocol Label Switchingpaquets appartenant à la même FEC subiront une commutation simple à travers ce c...
Chapitre I : MultiProtocol Label Switching                      PPP           En-tête PPP                 Shim MPLS       ...
Chapitre I : MultiProtocol Label SwitchingLorsque ce champ atteint 0, le paquet est rejeté. Lutilisation de ce champ évite...
Chapitre I : MultiProtocol Label Switching         Lutilisation de plusieurs niveaux de labels permet, lors dinterconnexio...
Chapitre I : MultiProtocol Label Switching    •      Descente à la demande (Downstream-on-Demand) :           Dans ce mode...
Chapitre I : MultiProtocol Label Switching   •   Par interface (per-interface label space) :       Les domaines de valeurs...
Chapitre I : MultiProtocol Label SwitchingEnfin, en présence dun nombre important de flux de trafic (sur un grand réseau),...
Chapitre I : MultiProtocol Label SwitchingProtocole de                                                                    ...
Chapitre I : MultiProtocol Label SwitchingLes principales applications de MPLS concernent :    •   Any Transport over MPLS...
Chapitre I : MultiProtocol Label Switchingdun client donné. Chaque site du VPN indique à lISP lensemble des préfixes (adre...
Chapitre I : MultiProtocol Label Switching5.3 Le support de la qualité de service (MPLS QoS)        Le support de la QoS p...
Chapitre II : MPLS Traffic Engineering                              Chapitre II :                         MPLS Traffic Eng...
Chapitre II : MPLS Traffic Engineering        Ceci peut conduire à quelques problèmes : supposant que tous les liens de la...
Chapitre II : MPLS Traffic Engineering    Les LSP ainsi construits sont appelés MPLS TE LSP ou TE tunnels. On sapprofondir...
Chapitre II : MPLS Traffic EngineeringAinsi, lingress LER pourra placer le trafic prioritaire dans un LSP, le trafic de mo...
Chapitre II : MPLS Traffic EngineeringLa création dun "MPLS TE LSP" suit les deux étapes suivantes :    •   Calcul du "MPL...
Chapitre II : MPLS Traffic Engineering3.1 Les messages RSVP TE3.1.1 Les types de messages RSVP TE        Il existe 9 types...
Chapitre II : MPLS Traffic Engineering      00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 ...
Chapitre II : MPLS Traffic EngineeringObject Length (16 bits) : La longueur de lobjet RSVP en octet, en-tête de lobjet inc...
Chapitre II : MPLS Traffic Engineering        Chacun des objets contenus dans un message RSVP TE rempli une fonction desig...
Chapitre II : MPLS Traffic Engineeringréseau sera véhiculé sur ce chemin. Enfin, un objet SESSION_ATTRIBUTE peut être ajou...
Chapitre II : MPLS Traffic Engineering        Nous allons résumer le processus détablissement des chemins avec lexemple de...
Chapitre II : MPLS Traffic Engineering    (9) R3 envoie un Resv message à R2, en signalant le label 21    (10)R2 envoie un...
Chapitre II : MPLS Traffic Engineering3.2.3 La signalisation des erreurs         De temps en temps, des problèmes peuvent ...
Chapitre II : MPLS Traffic Engineering   •   Notification messages : utilisés pour véhiculer les informations de supervisi...
Chapitre II : MPLS Traffic Engineering    (4) LSR B reçoit le LABEL_MAPPING message, il finalise la réservation, alloue un...
Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE                             Chapitre III :     ...
Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE1.2 Perte en paquets (Paquet Loss)        Généra...
Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE    •   Délai de traitement : Cest le temps que ...
Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE                               Emission         ...
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Mpls foudhaili oussama
Prochain SlideShare
Chargement dans…5
×

Mpls foudhaili oussama

2 023 vues

Publié le

0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 023
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
178
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Mpls foudhaili oussama

  1. 1. RAPPORT DE PROJET DE FIN D’ETUDES Filière Ingénieurs en Télécommunications Option Ingénierie des réseaux Analyse des performances de MPLSen terme de "Traffic Engineering" dans un réseau multiservice Elaboré par : Oussama FOUDHAILI Encadré par : M. Rached HAMZA M. Jamel SAKKA Année universitaire : 2004/2005
  2. 2. "Là où tout finira, là où tout commencera!" Confucius
  3. 3. Remerciements Je tiens tout d’abord à remercier Monsieur Rached Hamza (SupCom) pourmavoir fait lhonneur dêtre mon encadreur. Jadresse également mes très vifsremerciements à Monsieur Jamel Sakka (Tunisie Télécom) pour sa compétence, sapatience et son esprit ouvert et dynamique. Je tiens naturellement à remercier aussi le cadre enseignant et le corpsadministratif de SupCom pour mavoir donner laccès à une formation qui ma permisde maméliorer scientifiquement et humainement. Une pensée amicale est adressée à mes amis Kamel Zidane et Anis Souissiavec qui jai partagé le même foyer pendant trois ans et dont la présence ma permis demieux vivre aussi bien les temps de stress que les temps de bonheur. Finalement, que tous ceux qui ne sont pas nommés ici, mais qui ont contribuéde prés ou de loin au bon déroulement de ce projet, trouvent lassurance de ma pleinegratitude. Oussama Foudhaili
  4. 4. Table des MatièresIntroduction Générale 1Capitre I : MultiProtocol Label Switching (MPLS) 3 Introduction.................................................................................................................3 1 Principe de fonctionnement de MPLS .....................................................................3 2 Les labels .................................................................................................................5 3 Pile de labels (Label Stack) .....................................................................................7 4 Concepts relatifs à la distribution de labels .............................................................8 4.1 Contrôle de distribution des labels ....................................................................8 4.2 Distribution et gestion des labels ......................................................................8 4.3 Conservation des labels .....................................................................................9 4.4 Espace de labels (Label Space) .........................................................................9 4.5 Création des labels ..........................................................................................10 4.6 Modes de fonctionnement de quelques protocoles de distribution de label....11 5 Les applications de MPLS .....................................................................................12 5.1 Any Transport over MPLS (AToM) ...............................................................13 5.2 Le support des réseaux privés virtuels (MPLS VPN) .....................................13 5.3 Le support de la qualité de service (MPLS QoS)............................................15 5.4 Le Traffic Engineering (MPLS TE) ................................................................15 Conclusion................................................................................................................15Chapitre II : MPLS Traffic Engineering (MPLS TE) 16 Introduction...............................................................................................................16 1 Les motivations du Traffic Engineering ................................................................16 2 Calcul et établissement des "MPLS TE LSP" .......................................................19 3 Resource ReSerVation Protocol - Traffic Engineering (RSVP TE)......................20 3.1 Les messages RSVP TE ..................................................................................21 3.1.1 Les types de messages RSVP TE..............................................................21 3.1.2 Le format des messages RSVP TE ...........................................................21 3.1.3 Le format des objets RSVP TE.................................................................22 3.1.4 Le format des messages Path et Resv .......................................................23 3.2 Le fonctionnement de RSVP TE.....................................................................24 3.2.1 Létablissement et la maintenance des chemins ........................................24 3.2.2 La suppression des chemins ......................................................................27 3.2.3 La signalisation des erreurs.......................................................................28 4 Constraint-based Routing over Label Distribution Protocol (CR-LDP) ...............28 4.1 Les messages CR-LDP....................................................................................28 4.2 Le fonctionnement de CR-LDP.......................................................................29 Conclusion................................................................................................................30 -i-
  5. 5. Capitre III : Implémentation et simulation des fonctionnalités de MPLS TE 31 Introduction...............................................................................................................31 1 La qualité de service ..............................................................................................31 1.1 Bande Passante (Bandwidth)...........................................................................31 1.2 Perte en paquets (Paquet Loss)........................................................................32 1.3 Délai de bout en bout (End to End Delay) ......................................................32 1.4 Gigue (Jitter) ...................................................................................................33 1.5 Les exigences des différentes applications IP en terme de QoS .....................34 2 Lenvironneme nt de simulation..............................................................................35 2.1 Lintérêt d’utiliser un simulateur .....................................................................35 2.2 Présentation de NS2 ........................................................................................35 2.3 Fonctionnement de NS2 ..................................................................................36 2.4 Les modifications à apporter à NS2 ................................................................38 2.5 Avantages, limites et difficultés de NS2 .........................................................39 3 Simulation des fonctionnalités de MPLS TE.........................................................40 3.1 Le scénario de simulation................................................................................40 3.2 Résultats de la simulation et interprétations ....................................................42 3.2.1 "Bande passante" et "Taux de perte en paquets" ......................................43 3.2.2 "Délai de bout en bout " et "Gigue"...........................................................48 Conclusion................................................................................................................52Chapitre IV : Evaluation des performances de MPLS TE sur le backbone de "Tunisie Télécom" 53 Introduction...............................................................................................................53 1 Description du backbone MPLS de Tunisie Télécom...........................................53 1.1 Définition de Backbone ...................................................................................53 1.2 Structure du backbone de Tunisie Télécom....................................................54 2 Simulation et résultats............................................................................................57 2.1 Scénario de la simulation ................................................................................57 2.2 Résultats et interprétations ..............................................................................58 2.2.1 Estimation des charges des liens constituant le backbone ........................58 2.2.2 Estimation du délai ...................................................................................61 2.2.3 Estimation du taux de perte.......................................................................63 Conclusion................................................................................................................63Conclusion générale 65Références 67 - ii -
  6. 6. Table des figuresFigure 1.1 : Exemple dun réseau MPLS .......................................................................3Figure 1.2 : lencapsulation MPLS dans différentes technologies .................................6Figure 1.3 : Format du shim MPLS ...............................................................................6Figure 1.4 : Pile de labels...............................................................................................7Figure 1.5 : Unsolicited downsteam ..............................................................................8Figure 1.6 : Downsteam-on-demand ..............................................................................9Figure 1.7 : MPLS VPN...............................................................................................14Figure 2.1 : Le routage classique .................................................................................16Figure 2.2 : Le Traffic Engineering selon MPLS ........................................................18Figure 2.3 : Lencapsulation des messages RSVP TE..................................................21Figure 2.4 : Format des messages RSVP TE ...............................................................22Figure 2.5 : Format des objets RSVP TE.....................................................................22Figure 2.6 : Format du Path message ...........................................................................23Figure 2.7 : Format du Resv message ..........................................................................23Figure 2.8 : Path et Resv messages, lors de l établissement de chemin .......................26Figure 2.9 : Etablissement dun CR-LDP LSP.............................................................29Figure 3.1 : Illustration du concept de bande passante ................................................31Figure 3.2 : Illustration du concept de délai de bout en bout.......................................32Figure 3.3 : Illustration du concept de la gigue ...........................................................34Figure 3.4 : Les étapes d’une simulation sur NS2 .......................................................37Figure 3.5 : La topologie de simulation visualisée par NAM ......................................41Figure 3.6 : Bande Passante .........................................................................................43Figure 3.7 : Taux de paquets perdus ............................................................................43Figure 3.8 : Situation du trafic entre les instants 0.2s et 6s .........................................44Figure 3.9 : Situation du trafic entre les instants 6s et 7s ............................................44Figure 3.10 : Situation du trafic entre les instants 7s et 9s ..........................................45Figure 3.11 : Situation du trafic entre les instants 9s et 11s ........................................46Figure 3.12 : Situation du trafic entre les instants 11s et 13s ......................................46Figure 3.13 : Situation du trafic entre les instants 13s et 15s ......................................47Figure 3.14 : Délai de bout en bout ..............................................................................48Figure 3.15 : Gigue relatif au trafic TR .......................................................................48 - iii -
  7. 7. Figure 3.16 : Gigue relatif au trafic HP .......................................................................49Figure 3.17 : Gigue relatif au trafic BE .......................................................................49Figure 3.18 : Zoom relatif à la courbe de gigue...........................................................50Figure 3.19 : Zoom relatif à la courbe de délai entre les instant 8.5s et 8.85s.............51Figure 4.1 : La structure du backbone de Tunisie Télécom.........................................54Figure 4.2 : La disposition géographique du backbone de Tunisie Télécom ..............55Figure 4.3 : Backbone de Tunisie Télécom .................................................................55Figure 4.4 : le backbone tel que généré par NS2 .........................................................57Figure 4.5 : Occupation des liens (mode IP classique ) ................................................59Figure 4.6 : Occupation des liens (mode MPLS TE) ...................................................59Figure 4.7 : Exemple de route IP .................................................................................60Figure 4.8 : Exemple de route MPLS TE ....................................................................61Figure 4.9 : Délai normalisé par le nombre de saut .....................................................62Figure 4.10 : Le taux de perte ......................................................................................63 Liste des tableauxTableau 1.1 : Modes de fonctionnement de quelques protocoles de distribution de label........................................................................................................12Tableau 2.1 : Les messages RSVP TE.........................................................................21Tableau 3.1 : Les exigences des différentes applications IP en terme de QoS ............34Tableau 3.2 : Les flux considérés dans la simulation ..................................................41Tableau 3.3 : Timing de la simulation .........................................................................42Tableau 4.1 : Descriptif des liens raccordés au backbone ...........................................56Tableau 4.2 : Loccupation des liens ............................................................................59 - iv -
  8. 8. AcronymesACK acknowledgmentATM Asynchronous Transfer ModeAToM Any Transport over MPLSAWK Aho, Weinberger et KernighahnBE Best effort (acronyme propre à ce rapport)BGP Border Gateway ProtocolCBR Constant Bit RateCPU Central Processing UnitCR-LDP Constraint-based Routing over Label Distribution ProtocolCR-LSP Constraint-based Routing-LSPCSPF Constrained Shortest Path FirstEoIP Everything over IPER-LSP Explicit Routing -LSPFEC Forwarding Equivalence ClassFR Frame RelayFTP File Transfer ProtocolGCC GNU C/C++GMPLS Generalized MPLSHP Haute Priorité (acronyme propre à ce rapport)HTTP HyperText Transfer ProtocolICMP Internet Control Message ProtocolIETF Internet Engineering Task ForceIGP Interior Gateway ProtocolIP Internet ProtocolIS-IS Intermediate System-to-Intermediate SystemISP Internet Service ProviderLAN Local Area NetworkLDP Label Distribution ProtocolLER Label Edge RouterLSP Label Switched PathLSR Label Switch RouterMAC Media Access ControlMNS MPLS Network SimulatorMPLS MultiProtocol Label SwitchingNGN Next Generation NetworksNS2 Network Simulator 2OSPF Open Shortest Path FirstOTCL Object-oriented Tcl -v -
  9. 9. PHOP Previous HopPIM Protocol Independent MulticastPPP Point-to-Point ProtocolQoS Quality of ServiceRIP Routing Information ProtocolRSVP TE Resource ReSerVation Protocol - Traffic EngineeringSDH Synchronous Digital HierarchySONET Synchronous Optical NETworkSPF Shortest Path FirstSTM-x Synchronous Transport Module level xTCL Tool Command LangageTCP Transport Control ProtocolTDP Tag Distribution ProtocolTE Traffic EngineeringTR Temps Réel (acronyme propre à ce rapport)TTL Timt to liveUDP User Datagram ProtocolVCI Virtual Channel IdentifierVoIP Voice over IPVPI Virtual Path IdentifierVPN Virtual Private NetworkWAN Wide Area NetworkWFQ Weighted Fair Queuing - vi -
  10. 10. Introduction générale Introduction Générale La toile Internet connaît actuellement un développement vertigineux. Ce qui a fait deIP un protocole presque universel. Le succès de ce dernier repose sur sa grande simplicitépuisquil se base sur le modèle Best Effort. Toutefois, ce même point qui a fait sa force,constitue actuellement sa faiblesse. Car le modèle Best Effort a montré ses limites face auxnouveaux besoins des applications, puisque la demande sest diversifiée (data, voix, vidéo,etc.) et les services sont de plus en plus gourmands en ressources. Les nouvelles applicationsexigent aujourdhui de complexifier les réseaux et de prendre en compte les spécificationspropres à chacune delles pour quelles puissent fonctionner correctement. En, dautres termes,il est primordial dinstaurer la notion de la Qualité de Service (QoS) dans les réseaux télécom. La réponse à la question de QoS a été pour longtemps ATM. Car laspect non connectéde IP rend difficile denvisager de lui intégrer des services temps réel. Dun autre côté, les réseaux IP ont pris une ampleur tellement grande quon ne peutplus envisager de créer une architecture nouvelle répondant aux besoins de QoS. Et mêmelassociation IP/ATM a montré ses limites. La solution est alors de définir des mécanismescomplémentaires au fonctionnement de IP de base, permettant de prendre en compte lesexigences propres de chaque type de service. Ceci quitte à introduire une complexitésupplémentaire au fonctionnement de IP. Cest là que MPLS sest imposé comme une solution leader. MPLS a réussi àconjuguer la simplicité de IP avec lefficacité dATM dans la gestion du multiservice. MPLS fait également partie d’un mouvement d’ensemble vers les NGN (NextGeneration Networks) dont le but est de réaliser la convergence voix/données dans uneperspective générale de "tout IP" (EoIP : Everything over IP). MPLS constitue aussi une alternative à la commutation de circuit, encore largementutilisée en téléphonie. Ce type de commutation présente linconvénient de générer ungaspillage évident de ressources, puisque cest une technique à ressources dédiées. MPLSremédie à ce problème en mettant en œuvre des mécanismes permettant de faire passer dutrafic haute exigence, tel que la voix, dans un réseau à ressources partagées, sans pour autant -1-
  11. 11. Introduction généraledégrader sa qualité. On peut ainsi passer outre la technique de commutation de circuit etutiliser la commutation de paquet/label. Le réseau sera alors utilisé dune façon plus optimale,ce qui constitue un gain économique pour les opérateurs et les fournisseurs de services. De plus, avoir à gérer un seul réseau est très important pour un opérateur vu que ça luipermet de réduire ses coûts. Dautant plus que migrer vers les réseaux MPLS nest pas trèscoûteux puisquil existe des solutions qui nexigent pas de changer tous les équipements : onpeut juste patcher les routeurs déjà installés. Dans ce rapport, on va sintéresser à létude de MPLS et en particulier à lapplication"Traffic Engineering (TE)". Les chapitres I et II seront consacrés à une vue théorique de cesdeux concepts. Ensuite, on décrira, dans le chapitre III, limplémentation et les simulations quiont permis danalyser les performances de MPLS TE sur les réseaux multiservice. Pour enfinessayer dévaluer lapport du Trafic Engineering sur le backbone national de Tunisie Télécom. -2-
  12. 12. Chapitre I : MultiProtocol Label Switching Chapitre I : MultiProtocol Label Switching (MPLS) Introduction Précisons dès à présent que MPLS est davantage une architecture quun protocole ou un modèle de gestion. Ainsi, larchitecture MPLS est composée dun certain nombre de protocoles et de mécanismes définis, ou en cours de définition. Nous allons, le long de ce premier chapitre, faire le tour de la technologie MPLS. Nous commencerons par expliquer son principe de fonctionnement. Nous détaillerons ensuite les concepts relatifs aux labels et à leurs distributions. Nous finirons par donner un aperçu des applications que MPLS permet de réaliser. 1 Principe de fonctionnement de MPLS Ingress LER 12.3.2.125Site 1 LER L=18 LSR L=3 12.3.2.125 LSR Site 2 LSR Domaine LER Egress LER L=21 MPLS L=42 L=10921 LSR LSR LSR Figure 1.1 : Exemple dun réseau MPLS Un réseau MPLS est constitué de deux types déquipements : • LSR (Label Switch Router) : cest un équipement de type routeur, ou commutateur qui appartient à un domaine MPLS. -3-
  13. 13. Chapitre I : MultiProtocol Label Switching • LER (Label Edge Router) : cest un LSR qui fait linterface entre un domaine MPLS et le monde extérieur. En général, une partie de ses interfaces supportent le protocole MPLS et lautre un protocole de type IP. Il existe deux types de LER : - Ingress LER : cest un routeur qui gère le trafic qui entre dans un réseau MPLS. - Egress LER : cest un routeur qui gère le trafic qui sort dun réseau MPLS. Avant dexaminer le fonctionnement dun réseau MPLS, on va passer en revu leprincipe dacheminement des paquets dans un réseau IP classique et ainsi pouvoir faire unecomparaison des deux techniques. Dans un réseau IP classique, il y a mise en oeuvre dun protocole de routage (RIP,OSPF, IS-IS, etc.) Ce protocole sera exécuté indépendamment par chaque nœud. A laconvergence du protocole de routage, chaque nœud aura une vision plus ou moins complètedu réseau et pourra du coup calculer une table de routage contenant lensemble desdestinations. Chaque destination sera associée à un "prochain saut" ou "Next Hop". Voyant maintenant le cas dun réseau MPLS : La mise en œuvre de MPLS repose surla détermination de caractéristiques communes à un ensemble de paquets et dont dépendralacheminement de ces derniers. Cette notion de caractéristiques communes est appeléeForwarding Equivalence Class (FEC). Une FEC est la représentation d’un ensemble depaquets qui partagent les mêmes caractéristiques pour leur transport. - Le routage IP classique distingue les paquets en se basant seulement sur les adresses des réseaux de destination (préfixe d’adresse). - MPLS constitue les FEC selon de nombreux critères : adresse destination, adresse source, application, QoS, etc. Quand un paquet IP arrive à un ingress LER, il sera associé à une FEC. Puis, exactementcomme dans le cas dun routage IP classique, un protocole de routage sera mis en œuvre pourdécouvrir un chemin jusquà legress LER (Voir Figure 1.1, les flèches rouges). Mais à ladifférence dun routage IP classique cette opération ne se réalise quune seule fois. Ensuite,tous les paquets appartenant à la même FEC seront acheminés suivant ce chemin quonappellera Label Switched Path (LSP). Ainsi on a eu la séparation entre fonction de routage etfonction de commutation : Le routage se fait uniquement à la première étape. Ensuite tous les -4-
  14. 14. Chapitre I : MultiProtocol Label Switchingpaquets appartenant à la même FEC subiront une commutation simple à travers ce chemindécouvert. Pour que les LSR puissent commuter correctement les paquets, le Ingress LER affecte uneétiquette (appelée aussi Label) à ces paquets (label imposition ou label pushing). Ainsi, si onprend lexemple de la figure 1.1, Le LSR1 saura en consultant sa table de commutation quetout paquet entrant ayant le label L=18 appartient à la FEC tel et donc doit être commuté surune sortie tel en lui attribuant un nouveau label L=21 (label swapping). Cette opération decommutation sera exécuter par tous les LSR du LSP jusquà aboutir à lEgress LER quisupprimera le label (label popping ou label disposition) et routera le paquet de nouveau dansle monde IP de façon traditionnelle.Lacheminement des paquets dans le domaine MPLS ne se fait donc pas à base dadresse IPmais de label (commutation de label). Il est claire quaprès la découverte de chemin (par le protocole de routage), il fautmettre en œuvre un protocole qui permet de distribuer les labels entre les LSR pour que cesderniers puissent constituer leurs tables de commutation et ainsi exécuter la commutation delabel adéquate à chaque paquet entrant. Cette tâche est effectuée par "un protocole dedistribution de label" tel que LDP ou RSVP TE. Les protocoles de distribution de label serontrepris plus loin dans un paragraphe à part. Les trois opérations fondamentales sur les labels (Pushing, swapping et popping) sonttout ce qui est nécessaire pour MPLS. Le Label pushing/popping peuvent être le résultat duneclassification en FEC aussi complexe quon veut. Ainsi on aura placé toute la complexité auxextrémités du réseau MPLS alors que le cœur du réseau exécutera seulement la fonctionsimple de label swapping en consultant la table de commutation.2 Les labels Un label a une signification didentificateur local dune FEC entre 2 LSR adjacents etmappe le flux de trafic entre le LSR amont et le LSR aval. La figure 1.2, illustre la mise en œuvre des labels dans différentes technologies. Ainsi,MPLS fonctionne indépendamment des protocoles de niveau 2 (ATM, FR, etc.) et desprotocoles de niveau 3 (IP, etc.). Cest ce qui lui vaut son nom de "MultiProtocol LabelSwitching". -5-
  15. 15. Chapitre I : MultiProtocol Label Switching PPP En-tête PPP Shim MPLS En-tête couche 3 (Packet over SONET/SDH) Ethernet En-tête Ethernet Shim MPLS En-tête couche 3 Frame Relay En-tête FR Shim MPLS En-tête couche 3 ATM GFC VPI VCI PTI CLP HEC DATA Label Figure 1.2 : lencapsulation MPLS dans différentes technologies Dans le cas ATM, MPLS utilise les champs VPI (Virtual Path Identifier) et VCI(Virtual Channel Identifier) comme étant un label MPLS. Dans les autres cas, MPLS insère un en-tête (32 bits) entre la couche 2 et la couche 3appelé shim MPLS. La figure 1.3 illustre le format dun shim MPLS : 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 LABEL EXP S TTL Figure 1.3 : Format du shim MPLSLABEL (20 bits) : Contient le label.EXP (3 bits) : Initialement réservé pour une utilisation expérimentale. Actuellement, la pluspart des implémentations utilise ce champ comme indicateur de QoS. Généralement, cest unecopie du champ PRECEDENCE (PPP) dans len-tête IP. En IP, la précédence définit lapriorité dun paquet (0 : priorité supérieure, 7 : priorité inférieure).S (1 bit) : Indique sil y a empilement de labels (il est en fait commun davoir plus quun labelattaché à un paquet). Cette notion sera reprise dans le paragraphe suivant. Le bit S est à 1lorsque le label se trouve au sommet de la pile, à 0 sinon.TTL (8 bits) : Même signification que pour IP. Ce champ donne la limite supérieure aunombre de routeurs quun paquet peut traverser. Il limite la durée de vie du paquet. Il estinitialisé à une certaine valeur, puis décrémenté de un par chaque routeur qui traite le paquet. -6-
  16. 16. Chapitre I : MultiProtocol Label SwitchingLorsque ce champ atteint 0, le paquet est rejeté. Lutilisation de ce champ évite les boucles deroutage.3 Pile de labels (Label Stack) Comme on la déjà évoqué, il est commun davoir plus quun label attaché à un paquet.Ce concept sappelle empilement de label. Lempilement de label permet en particulierdassocier plusieurs contrats de service à un flux au cours de sa traversée du réseau MPLS.Dans le cas de deux niveaux de label, on pourra relier deux réseaux dun réseau privé autravers dun réseau opérateur (Voir figure 1.4), en utilisant un niveau de labels au niveauopérateur, et un niveau de labels au niveau du réseau privé. Les LSR de frontière de réseauauront donc la responsabilité de pousser (ou tirer) la pile de labels pour désigner le niveaudutilisation courant de label. 10.2.0.174 10.2.0.174 Site 1 Site 2 3 1 9 2 6 4 2 Domaine MPLS 9 2 Opérateur 8 2 6 2 7 2 Figure 1.4 : Pile de labels -7-
  17. 17. Chapitre I : MultiProtocol Label Switching Lutilisation de plusieurs niveaux de labels permet, lors dinterconnexions de disposerde plusieurs niveaux dopérateurs. Chacun manipule les labels correspondant à son niveau [1].4 Concepts relatifs à la distribution de labels Pour comprendre comment les LSR génèrent et distribuent les labels, on doit aborderquelques concepts relatifs à la distribution de labels [1].4.1 Contrôle de distribution des labelsIl existe deux modes de contrôle de distribution des labels aux LSR voisins : • Mode de contrôle ordonné (Ordered control mode) : Dans ce mode, un LSR associe un label à une FEC particulière, si : ü Il sagit dun Egress LER ; ü Lassignation (lassociation Label, FEC) a été reçue du LSR situé au saut suivant. • Mode de contrôle indépendant (Independent control mode) : Dans ce mode, les LSR sont libres de communiquer les associations entre label et FEC à leurs voisins sans attendre de recevoir lassignation du LSR situé au saut suivant. Ainsi, un LSR peut diffuser un label pour une FEC, quand bien même il nest pas prêt à communiquer sur ce label.4.2 Distribution et gestion des labelsLa distribution elle-même des labels peut se faire suivant plusieurs méthodes : • Descente systématique (unsolicited downstream) : Le LSR en aval envoie le label au LSR précédent (en amont) de manière systématique (sans demande explicite). Ainsi dans lexemple de la figure 1.5, LSR C demande au LSR B dutiliser le Label 53 Pour la destination 182.65.10/24. LSR B, à son tour, demande au LSR A dutiliser le label 25 pour cette même destination. Utilisez le label 25 pour la Utilisez le label 53 pour la 182.65.10/24 destination 182.65.10/24 destination 182.65.10/24 182.65.10/24 LSR A LSR B LSR C Figure 1.5 : Unsolicited downsteam -8-
  18. 18. Chapitre I : MultiProtocol Label Switching • Descente à la demande (Downstream-on-Demand) : Dans ce mode, le LSR en aval envoie le label au LSR précèdent uniquement sil a reçu une requête. Et ceci même sil a déjà généré un label pour la FEC en question. Utilisez le label 25 pour la Utilisez le label 53 pour la 182.65.10/24 destination 182.65.10/24 destination 182.65.10/24 182.65.10/24 LSR A LSR B LSR C Demande de label pour la Demande de label pour la destination 182.65.10/24 destination 182.65.10/24 Figure 1.6 : Downsteam-on-demand4.3 Conservation des labelsIl existe deux modes que les LSR utilisent pour la conservation des labels reçus : • Mode de conservation libéral (Liberal retention) : Dans ce mode, les LSR conservent les labels reçus de tous leurs voisins. Il permet une convergence plus rapide face aux modifications topologiques du réseau et la commutation de trafic vers dautres LSP en cas de changement. En contre partie, ce mode nécessite beaucoup de mémoire. • Mode de conservation conservateur (Conservative retention) : Dans ce mode, les LSR retiennent uniquement les labels des voisins situés sur le saut suivant et ignorent tous les autres. Ce mode nécessite peu de mémoire. En contre partie, on aura une adaptation plus lente en cas derreur4.4 Espace de labels (Label Space) Les labels utilisés par un LSR pour lassignation de labels à un FEC sont définis de deuxfaçons : • Par plate-forme (per-platform label space ou global space) : Dans ce cas, les valeurs de labels sont uniques dans tous les équipements LSR. Les labels sont alloués depuis un ensemble commun de labels : de la sorte, deux labels situés sur des interfaces distinctes possèdent des valeurs distinctes. -9-
  19. 19. Chapitre I : MultiProtocol Label Switching • Par interface (per-interface label space) : Les domaines de valeurs des labels sont associés à une interface. Plusieurs peuvent être définis. Dans ce cas, les valeurs de labels fournies sur des interfaces différentes peuvent être identiques. Il est clairement stipulé quun LSR peut utiliser une assignation de label par interface, à la condition express quil soit en mesure de distinguer linterface depuis laquelle arrive le paquet. Il risque sinon de confondre deux paquets possédant le même label, mais issus dinterfaces différentes.4.5 Création des labels Plusieurs méthodes sont utilisées pour la création des labels, en fonction des objectifsrecherchés. • Fondée sur la topologie (Topology-based) : Cette méthode engendre la création de labels à l’issue de l’exécution normale des processus de routages (comme OSPF ou BGP). • Fondée sur les requêtes (Request-based) : Cette méthode de création de labels est déclenchée lors de l’exécution d’une requête de signalisation. • Fondée sur le trafic (Traffic-based) : Cette méthode de création de labels attend la réception d’un paquet de donnée pour déclancher l’assignation et la distribution de labels. Le protocole IP-Switching de la société Ipsilon illustre cette méthode. La dernière méthode est un exemple de protocole fondé sur le modèle orienté données(data-driven). Ce modèle na pas été retenu par MPLS. Dans ce cas, lassignation de labelsnest déclenchée quà la réception effective de paquets de données et non a priori comme enmode control-driven. Cette méthode présente lavantage de justifier le processus de créationde labels et de leur distribution qui se fait uniquement en présence effective dun traficutilisateur. En revanche, elle a linconvénient dobliger lensemble des routeurs du réseau àfonctionner au départ comme des routeurs traditionnels, avec lobligation de disposer desfonctions de classification de paquets pour identifier les flux de trafic. En outre, il existe undélai entre la reconnaissance dun flux sur le réseau et la création dun label pour ce flux. - 10 -
  20. 20. Chapitre I : MultiProtocol Label SwitchingEnfin, en présence dun nombre important de flux de trafic (sur un grand réseau), le processusde distribution de labels peut devenir complexe et lourd à gérer. Les deux premières méthodes exposées sont des exemples dassignation de labelsétablis à partir du modèle orienté contrôle ( control-driven), à savoir quà linverse du modèleprécédent, les labels sont assignés et distribués préalablement à larrivée des données de traficde lutilisateur. Cest le modèle retenu et utilisé par MPLS.Voici les principaux protocoles de distribution de labels envisagés : • TDP (Tag Distribution Protocol) : Prédécesseur de LDP. • LDP (Label Distribution Protocol) : Protocole créé spécifiquement. • BGP (Border Gateway Protocol) : Amélioration de BGP pour la distribution des labels • PIM (Protocol Independent Multicast) : Amélioration de PIM pour la distribution des labels • CR-LDP (Constraint-based Routing LDP) : Amélioration de LDP • RSVP TE (Ressource ReSerVation Protocol Traffic Engineering) : Amélioration de RSVP Les quatre premières approches sont fondées sur la topologie (Topology-based). Les deuxdernières approches sont fondées sur les requêtes (Request-based). Et ce sont ces deuxprotocoles de distribution de labels qui sont utilisés pour le MPLS Traffic Engineering. On vales revoir plus en détail dans le chapitre II et on va consacrer notre étude pratique à lasimulation du protocole RSVP TE.4.6 Modes de fonctionnement de quelques protocoles de distribution de label Le tableau [3] ci-dessous présente quelques protocoles de distribution de labels etleurs modes de fonctionnements respectifs : - 11 -
  21. 21. Chapitre I : MultiProtocol Label SwitchingProtocole de Espace dedistribution Contrôle Distribution Conservation Création label de label Downstream Topology-TDP et LDP Unordered Liberal Per platform unsolicited basedTDP et LDP Downstream on Topology- Ordered Conservative Per interface(avec ATM) Demand based Downstream on Request- RSVP TE Ordered Conservative Per platform Demand based Unordered/ Downstream unsolicited/ Liberal/ Per platform/ Request- CR-LDP Ordered Downstream on Demand Conservative Per interface based Tableau 1.1 : Modes de fonctionnement de quelques protocoles de distribution de label 5 Les applications de MPLS La motivation primaire de MPLS était daccroître la vitesse de traitement des paquets au niveau des nœuds intermédiaires. Cela dit, aujourdhui MPLS offre peu sinon pas damélioration du tout dans ce sens : les routeurs actuels sont équipés avec des circuits et des algorithmes permettant un acheminement (forwarding) des paquets extrêmement rapide. Donc, traiter des paquets sur la base de label de 20 bits de MPLS nest plus significativement rapide par rapport à traiter des paquets sur la base dadresse de 32 bits de IP. Aujourdhui, les motivations réelles pour déployer des solutions MPLS sont les applications que MPLS permet et qui étaient très difficiles voire impossibles à mettre en œuvre avec IP traditionnel. Ces applications sont très importantes pour les opérateurs et les ISP (Internet Service Provider), tout simplement parce quelles peuvent être vendues Il existe aujourdhui quatre applications majeures de MPLS. Ces applications supposent la mise en œuvre de composants adaptés aux fonctionnalités recherchées. Limplémentation de MPLS sera donc différente en fonction des objectifs recherchés. Cela se traduit principalement par une façon différente dassigner et de distribuer les labels (Classification, protocoles de distribution de labels). Le principe dacheminement des paquets fondé sur lexploitation des labels étant le mécanisme de base commun à toutes les approches. - 12 -
  22. 22. Chapitre I : MultiProtocol Label SwitchingLes principales applications de MPLS concernent : • Any Transport over MPLS (AToM) ; • Le support des réseaux privés virtuels (MPLS VPN, Virtual Private Network) ; • Le support de la qualité de service (MPLS QoS) ; • Le Traffic Engineering (MPLS TE).5.1 Any Transport over MPLS (AToM) Ce service traduit lindépendance de MPLS vis-à-vis des protocoles de couches 2 et 3.AToM est une application qui facilite le transport du trafic de couche 2, tel que Frame Relay,Ethernet, PPP et ATM, à travers un nuage MPLS [3].5.2 Le support des réseaux privés virtuels (MPLS VPN) Un réseau privé virtuel (VPN) simule le fonctionnement dun réseau étendu (WAN) privésur un réseau public comme Internet. Afin doffrir un service VPN fiable à ses clients, unopérateur ou un ISP doit alors résoudre deux problématiques essentielles : • Assurer la confidentialité des données transportées ; • Prendre en charge des plans dadressage privé, fréquemment identiques.La construction de VPN repose alors sur les fonctionnalités suivantes : • Systèmes de pare-feu (Firewall) pour protéger chaque site client et permettre une interface sécurisée avec Internet ; • Système dauthentification pour vérifier que chaque site client échange des informations avec un site distant valide ; • Système de cryptage pour empêcher lexamen ou la manipulation des données lors du transport sur Internet ; • Tunneling pour permettre un service de transport multiprotocole et lutilisation de plans dadressage privés MPLS permet de résoudre efficacement la fonctionnalité de tunneling, dans la mesure oùlacheminement des paquets nest pas réalisé sur ladresse de destination du paquet IP, maissur la valeur du label assigné au paquet [1]. Ainsi, un ISP peut mettre en place un VPN, endéployant un ensemble de LSP pour permettre la connectivité entre différents sites du VPN - 13 -
  23. 23. Chapitre I : MultiProtocol Label Switchingdun client donné. Chaque site du VPN indique à lISP lensemble des préfixes (adresses)joignables sur le site local. Le système de routage de lISP communique alors cetteinformation vers les autres sites distants du même VPN, à laide du protocole de distributionde labels. En effet, lutilisation didentifiant de VPN permet à un même système de routage desupporter multiples VPN, avec un espace dadressage éventuellement identique. Ainsi, chaqueLER place le trafic en provenance dun site dans un LSP fondé sur une combinaison deladresse de destination du paquet et lappartenance à un VPN donné. VPN 2 LER VPN 1 LER VPN 2 LER VPN 2 LER VPN 1 LER LER VPN 1 Figure 1.7 : MPLS VPN Il existe une autre approche permettant de mettre en œuvre des VPN sur les réseau IP :IPSec. IPSec privilégie la sécurisation des flux dinformation par encryptage des données,alors que MPLS se concentre plutôt sur la gestion de la qualité de service et la priorité desflux. Le problème de sécurité dans MPLS VPN est minimal dans le cas où le réseau estpropriétaire (non Internet). Cependant, si cette garantie nest pas suffisante, il existe dessolutions qui permettent dutiliser en même temps MPLS et IPSec [2] et ainsi construire desVPN disposant des avantages des deux approches en même temps : la souplesse de MPLS etla sécurisation de IPSec. - 14 -
  24. 24. Chapitre I : MultiProtocol Label Switching5.3 Le support de la qualité de service (MPLS QoS) Le support de la QoS peut être mise en œuvre de deux façons sur MPLS [1] : • Les trafics sur un même LSP peuvent se voir affecter à différentes files dattente dans les routeurs LSR, selon la valeur du champ EXP de len-tête MPLS (Voir Figure 1.3). Le principe du champ EXP dans MPLS est le même que le champ Precedence (PPP) dans IP (Voir plus haut le détail de ce champ). • Lutilisation du Traffic Engineering,5.4 Le Traffic Engineering (MPLS TE) Cette application est en étroite relation avec la Qualité de Service, puisque sontrésultat immédiat est lamélioration de paramètres tel que le délai ou la gigue dans le réseau.Elle est tout de même considérée comme une application à part entière par la plupart desindustriels. Ceci vient du fait que MPLS TE nest pas une simple technique de réservation deressources pour les applications réseau. Cest un concept plus global qui se veut être unesolution qui vise à augmenter les performances générales du réseau en jouant sur la répartitionéquilibrée des charges (trafics) dans le réseau pour ainsi avoir une utilisation plus optimaledes liens. Le Traffic Engineering va être repris dune façon théorique dans le chapitre II, puis àtravers les simulations dans les chapitres III et IV.Conclusion Même si le temps de routage n’est plus l’intérêt de cette technologie, MPLS esttoujours très favorable pour simposer dans le monde des réseaux. Les offres MPLS au niveau de la qualité de service, de VPN ou de Traffic Engineeringassureront à ce protocole un succès tant au près des utilisateurs que des opérateurs etfournisseurs de services. Son succès vient également du fait qu’il ne remet pas en cause lesprotocoles existants de niveau 2 et 3. Dans le chapitre qui va suivre, on va sapprofondir dans la notion de TrafficEngineering et voir comment MPLS traite ce concept. - 15 -
  25. 25. Chapitre II : MPLS Traffic Engineering Chapitre II : MPLS Traffic Engineering (MPLS TE)Introduction Dans ce chapitre, on va commencer par expliquer la notion de Traffic Engineering etles améliorations quil permet dapporter à lutilisation du réseau. Ensuite, on va aborder lesmécanismes et protocoles qui permettent de mettre en œuvre des solutions MPLS TE dans unréseau.1 Les motivations du Traffic Engineering Le chemin le plus court R1 R5 Coût : 15 R6 R2 Coût : 15 Coût : 15 Coût : 15 Coût : 15 R7 Coût : 15 R3 R4 Coût : 15 Figure 2.1 : Le routage classiqueDans la figure 2.1, Il existe deux chemins pour aller de R2 à R6 : • R2 à R5 à R6 • R2 à R3 à R4 à R6 En IP classique, Le protocole de routage (OSPF, IS-IS, etc.) va se baser sur le critèredu plus court chemin [3]. Et puisque tous les liens ont le même coût (15), les paquets venantde R1 ou R7 est qui sont destinés à R6 vont tous suivre le même chemin (R2 à R5 à R6). - 16 -
  26. 26. Chapitre II : MPLS Traffic Engineering Ceci peut conduire à quelques problèmes : supposant que tous les liens de la figure 2.1supportent une bande passante de 150Mbps. Et supposant que R envoie en moyenne 90Mbps 1à R6. Le protocole de routage va faire de sorte que ce trafic utilise le plus court chemin, soitR2 à R5 à R6. Si maintenant R7 veut envoyer 100Mbps à R6. La même procédure deroutage fera que ce trafic utilisera aussi le chemin e plus court. En final, on aura deux trafics lde 190Mbps en total qui veulent tous deux utiliser le chemin le plus court (R2 à R5 à R6),alors que ce chemin ne peut supporter que 150Mbps. Ceci va induire des files dattente et despertes de paquets. Cet exemple est un cas explicite de sous utilisation des ressources duréseau vu que réellement, il existe un chemin dans le réseau qui nest pas exploité et que sonutilisation aurait permis de satisfaire les deux trafics. Comment peut on alors résoudre ce problème? Avec IP classique on pourra faire desorte que les deux chemins aient le même coût. Cependant cette solution marche seulementavec des réseaux de petite taille comme dans notre cas. Mais que ce passera-t-il si au lieudavoir sept routeurs, on ait eu 500? Les réseaux ATM permettent aussi de réaliser une telle ingénierie des flux. Leproblème cest quils introduisent en parallèle une grande complexité de gestion : en effet IP etATM sont deux techniques réseaux totalement différentes, avec parfois des contraintes noncompatibles. Contrairement aux solutions IP et ATM, MPLS va permettre une simplificationradicale de lintégration de cette fonctionnalité dans les réseaux. MPLS TE permet à lingress LER de contrôler le chemin que son trafic va emprunterpour atteindre une destination particulière. Ce concept est connu sous le nom de "ExplicitRouting". Cette méthode est plus flexible que lacheminement du trafic basé seulement surladresse destination. MPLS TE réserve de la bande passante en construisant les LSP. Ainsidans la topologie de la figure 2.2, LSR2 a la possibilité de construire deux LSP (Tunnel1 etTunnel2) relatifs aux chemins : • LSR2 à LSR5 à LSR6 • LSR2 à LSR3 à LSR4 à LSR6 - 17 -
  27. 27. Chapitre II : MPLS Traffic Engineering Les LSP ainsi construits sont appelés MPLS TE LSP ou TE tunnels. On sapprofondiradans les mécanismes de création des MPLS TE LSP dans le paragraphe 2. Tunnel1 R1 LSR5 Coût : 15 LSR6 LSR2 Coût : 15 Coût : 15 Coût : 15 Coût : 15 R7 Coût : 15 LSR3 LSR4 Coût : 15 Tunnel2 Figure 2.2 : Le Traffic Engineering selon MPLS La souplesse de lutilisation des labels dans MPLS TE permet de profiter desavantages suivants : • Le routage des chemins primaires autour de points de congestion connus dans le réseau (le contournement de la congestion) ; • Le contrôle précis du re-routage de trafic, en cas dincident sur le chemin primaire. (On sous-entend par re-routage : la modification du LSP en cas derreur (routeur en panne, manque de ressources)) ; • Un usage optimal de lensemble des liens physiques du réseau, en évitant la surcharge de certains liens et la sous-utilisation dautres. Cest ce quon appelle léquilibrage des charges ou load balancing. Le Traffic Engineering permet ainsi daméliorer statistiquement les paramètres de QoS(Taux de perte, délai, gigue, etc.) Un exemple concret de Traffic Engineering est quil est possible de définir plusieursLSP entre chaque couple de LER. Chaque LSP peut être conçu (grâce aux techniques deTraffic Engineering) pour fournir différentes garanties de bande passante ou de performances. - 18 -
  28. 28. Chapitre II : MPLS Traffic EngineeringAinsi, lingress LER pourra placer le trafic prioritaire dans un LSP, le trafic de moyennepriorité dans un autre LSP et enfin le trafic best effort dans un troisième LSP.2 Calcul et établissement des "MPLS TE LSP" Dans un protocole de routage à état de lien (tel que OSPF ou IS-IS), chaque routeurconnaît tous les routeurs du réseau et les liens qui connectent ces routeurs.Aussi tôt quun routeur se fait une idée de la topologie du réseau, il exécute le "DijkstraShortest Path First algorithm" (SPF) pour déterminer le plus court chemin entre lui-même ettous les autres routeurs du réseau (Construction de la table de routage). Etant donné que tousles routeurs exécutent le même calcul sur les mêmes données, chaque routeur aura la mêmeimage du réseau, et les paquets seront routés de manière cohérente à chaque saut. Le processus qui génère un chemin pour un "MPLS TE LSP" est différent du SPFclassique, mais pas trop. Il y a deux différences majeures entre le SPF classique, utilisée parles protocoles de routage, et le CSPF (Constrained Shortest Path First), utilisé par MPLS TE : • Le processus de détermination de chemin nest pas conçu pour trouver le plus court chemin, mais il tient compte dautres contraintes ; • Il y a plus dune métrique à chaque nœud, au lieu dune seule comme dans le cas de OSPF et IS-IS. A remarquer que ladministrateur nest pas obligé de passer p CSPF pour calculer un arMPTS TE LSP. Il peut manuellement imposer un chemin explicite à une FEC donnée. Danscertaines littératures, on appelle les TE LSP calculés par des algorithmes basés sur la situationdu trafic des CR-LSP (Constraint-based Routing - LSP), et les TE LSP spécifiésexplicitement par ladministrateur des ER-LSR (Explicit Routing - LSP).MPLS crée les LSP différemment selon quon utilise le Traffic Engineering ou non.La création dun "MPLS LSP", dans le cas non TE, suit les deux étapes suivantes : • Calcul du "MPLS LSP" : Mise en œuvre de lalgorithme SPF (OSPF ou IS-IS). • Etablissement du "MPLS LSP" : Mise en œuvre dun protocole de distribution de label Topology-based (LDP, BGP, PIM). - 19 -
  29. 29. Chapitre II : MPLS Traffic EngineeringLa création dun "MPLS TE LSP" suit les deux étapes suivantes : • Calcul du "MPLS TE LSP" : Mise en œuvre de l’algorithme CSPF ou intervention manuelle de ladministrateur pour imposer une route explicite. • Etablissement du "MPLS TE LSP" : Mise en œuvre dun protocole de distribution de label Request-based (RSVP TE, CR-LDP).Après avoir calculer un chemin avec CSPF, ce chemin doit être signalé à travers le réseau, etceci pour deux raisons : • Etablir une chaîne de labels qui représente le chemin ; • Réserver les ressources nécessaires (bande passante) à travers le chemin. Dans ce qui suit, on va détailler létape de létablissement du "MPLS TE LSP" enexaminant de prés le fonctionnement des protocoles de distribution de labels RSVP TE et CR-LDP. On va se concentrer plus sur RSVP TE vu que létude pratique porte sur ce protocole.3 Resource ReSerVation Protocol - Traffic Engineering (RSVP TE) Ce protocole [3] est originalement destiné à être un protocole de signalisation pourIntServ (Cest un modèle de QoS où une machine demande du réseau une QoS donnée pourun fux donné). RSVP avec quelques extensions a été adapté par MPLS pour être un protocole lde signalisation qui supporte MPLS TE. Nous allons, dans cette partie, commencer par illustrer le format général des messagesRSVP TE. Pour enfin expliquer avec plus ou moins de détails le fonctionnement de ceprotocole. - 20 -
  30. 30. Chapitre II : MPLS Traffic Engineering3.1 Les messages RSVP TE3.1.1 Les types de messages RSVP TE Il existe 9 types de messages RSVP TE qui sont résumés dans le tableau 2.1. Type de message Description Path Utilisé pour létablissement et le maintien des chemins Resv Envoyé en réponse au message Path Analogue au message Path, mais utilisé pour supprimer les PathTear réservations du réseau Analogue au message Resv, mais utilisé pour supprimer les ResvTear réservations du réseau Envoyé par un récepteur dun message Path qui détecte une erreur PathErr dans ce message Envoyé par un récepteur dun message Resv qui détecte une ResvErr erreur dans ce message Optionnellement envoyé à lémetteur dun message Resv pour ResvConf confirmer quune réservation donnée est bien établie Analogue à ResvConf. Optionnellement envoyé à lémetteur dun ResvTearConf message ResvTear pour confirmer quune réservation donnée est supprimée Hello Envoyé entre voisins directement connectés Tableau 2.1 : Les messages RSVP TE3.1.2 Le format des messages RSVP TE Un message RSVP TE est constitué dun en-tête commun (commun Header) et dunnombre variable dobjets selon le type de message (voir figure 2.4). En-tête MAC En-tête IP Message RSVP TE Figure 2.3 : Lencapsulation des messages RSVP TE - 21 -
  31. 31. Chapitre II : MPLS Traffic Engineering 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Version Flags Message type RSVP checksum Common Header Send TTL Reserved RSVP length Objects Figure 2.4 : Format des messages RSVP TEVersion (4 bits) : La version du protocole RSVP. La version actuelle de RSVP est 1.Flags (4 bits) : Encore non définit.Message Type (8 bits) :1 = Path message 6 = ResvTear message2 = Resv message 7 = ResvConf message3 = PathErr message 10 = ResvTearConf message4 = ResvErr message 20 = Hello message5 = PathTear messageRSVP Checksum (16 bits) : Utilisé pour la détection derreur. Même principe que pour lechamp Chechsum de IP.Send TTL (8 bits) : Contient la valeur du TTL, dans la paquet IP, avec lequel ce message aété envoyé.Reserved (8 bits) : Non utilisé.RSVP Length (16 bits) : La longueur de message RSVP en octet, common header inclus. Lavaleur de ce champ est donc toujours supérieure à 8.3.1.3 Le format des objets RSVP TE Chaque message RSVP TE peut contenir plusieurs objets. Le format général dunobjet RSVP TE est le suivant : 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Object length Class-num C-type Object contents Figure 2.5 : Format des objets RSVP TE - 22 -
  32. 32. Chapitre II : MPLS Traffic EngineeringObject Length (16 bits) : La longueur de lobjet RSVP en octet, en-tête de lobjet inclus. Lavaleur de ce champ est donc toujours supérieure à 4.Class-Num (8 bits) : La classe de lobjet.C-Type (8 bits) : Le type de classe de lobjet.Object Contents (longueur variable) : Lobjet lui-même. Chaque classe a son propre espace de numéro C-Type. Par exemple, la classeSESSION a 4 C-Types : IPv4, IPv6, LSP_TUNNEL_IPv4, et LSP_TUNNEL_IPv6. Lesnuméros assignés à ces C-Types sont 1, 2, 7 et 8. LABEL_REQUEST a 3 C-Types : WithoutLabel Range, With ATM Label Range, and With Frame Relay Label Range. Les numérosassignés à ces C-Types sont 1, 2, et 3. Ainsi pour identifier le contenu dun message, on doitprendre en compte les n uméros de classe et le numéro de C-Type. On peut voir les classes etC-Types comme une sorte du numérotation hiérarchique.3.1.4 Le format des messages Path et ResvEn voici le format des deux principaux messages de RSVP TE ([..] : optionnel) : Common Header [INTEGRITY] Common Header SESSION [INTEGRITY] PHOP SESSION TIME_VALUES NHOP [EXPLICIT_ROUTE] TIME_VALUES [RESV_CONFIRM] LABEL_REQUEST Objets [SCOPE] [SESSION_ATTRIBUTE] [POLICY_DATA] [POLICY_DATA] STYLE SENDER_TEMPLATE FLOWSPEC SENDER_TSPEC FILTER_SPEC [ADSPEC] LABEL [RECORD_ROUTE] [RECORD_ROUTE] Figure 2.6 : Format du Path message Figure 2.7 : Format du Resv message - 23 -
  33. 33. Chapitre II : MPLS Traffic Engineering Chacun des objets contenus dans un message RSVP TE rempli une fonction designalisation particulière. Des exemples seront donnés dans le paragraphe suivant.3.2 Le fonctionnement de RSVP TE RSVP TE est un mécanisme de signalisation utilisé pour réserver des ressources àtravers un réseau. RSVP TE nest pas un protocole de routage. Toute décision de routage estfaite par IGP (Interior Gateway Protocol). Le seul travail de RSVP TE est de signaler et demaintenir la réservation de ressources à travers le réseau.RSVP TE a trois fonctions de base : • Létablissement et la maintenance des chemins (Path setup and maintenance) • La suppression des chemins (Path teardown) • La signalisation des erreurs (Error signalling) RSVP TE est un "soft-state protocol". Cela veut dire quil a besoin de rafraîchirpériodiquement ses réservations dans le réseau. Ceci est différent des "hard-state protocol",qui signalent leurs requêtes une seule fois et puis supposent quelle reste maintenue jusquà sarésiliation explicite. Avec RSVP TE, une requête est résiliée si elle lest explicitement duréseau par RSVP TE ou si la durée de réservation expire.3.2.1 Létablissement et la maintenance des chemins Bien que létablissement et la maintenance des chemins soient des concepts trèsproches et utilisent les mêmes formats de messages, toutefois, ils différent légèrement. Cestpourquoi, on va les expliquer séparément. • Létablissement des chemins Après que lingress LER (appelé aussi MPLS TE tunnel headend ou headend) aitterminé sa procédure CSPF pour un tunnel particulier, il doit signaler le chemin trouvé àtravers le réseau. Le headend réalise cette opération en envoyant un Path message au prochainsaut (next hop) dans le chemin calculé vers la destination.Ce Path message contient un objet EXPLICIT_ROUTE qui contient le chemin calculé parCSPF sous la forme dune séquence de nœuds. Le headend ajoute un objet LABEL_REQUESTqui indique quune association de label est requise pour ce chemin et quel type de protocole - 24 -
  34. 34. Chapitre II : MPLS Traffic Engineeringréseau sera véhiculé sur ce chemin. Enfin, un objet SESSION_ATTRIBUTE peut être ajouté auPath message pour faciliter lidentification de la session et les diagnostics.Finalement, le Path message est acheminé vers le lEgress LER (appelé aussi MPLS TEtunnel tail ou tail) en suivant la route spécifiée dans lobjet EXPLICIT_ROUTE. Au fur est àmesure de lavancement du Path message, chaque LSR intermédiaire effectue les deux actionssuivantes : • Il vérifie le format du message pour sassurer quil nest pas corrompu • Il vérifie la quantité de bande passante que le Path message reçu demande en utilisant les informations contenues dans les objets SESSION_ATTRIBUTE, SENDER_TSPEC et POLICY_DATA. Ce processus est appelé "contrôle dadmission".Si le contrôle dadmission réussit et le Path message est autorisé à réserver la bande passantequil demande, le LSR intermédiaire crée un nouveau Path message et lenvoie au "next hop"(en se référant à lobjet EXPLICIT_ROUTE). Les Path messages refont cette procédure avec tous les routeurs du chemin à établirjusquà atteindre le dernier nœud dans lEXPICITE_ROUTE. Le tunnel tail réalise le contrôledadmission en le Path message, exactement comme nimporte quel nœud intermédiaire.Quand le tail réalise quil est la destination du Path message, il répond par un Resv message.On peut considérer le Resv message comme un acquittement (ACK) pour le saut précédent(Previous Hop, PHOP).Le Resv message nest pas quun acquittement témoignant de la réussite de la réservation,mais il contient aussi le incoming label que le Previous Hop doit utiliser pour lenvoie depaquets de données le long du TE LSP jusquau tail. En effet, Lobjet LABEL_REQUEST(Path message) réclame aux LSR traversés et au tail une association de label pour la session.Le tail répond au LABEL_REQUEST en incluant un objet LABEL dans son message deréponse RESV. Puis le RESV message est renvoyé vers le headend, en suivant le chemininverse à celui spécifié dans lobjet EXPLICIT_ROUTE. Chaque LSR qui reçoit le messageRESV contenant lobjet LABEL utilisera ce label pour le trafic de donnée sortant. Si le LSRnest pas le headend, il alloue un nouveau label quil place dans lobjet LABEL du RESVmessage, et quil fait transiter sur le chemin inverse (grâce à linformation PHOP quil auramémorisée lors du passage du PATH message pendant le processus daller). Quand le RESVmessage arrive au headend, le TE LSP est effectivement créé. A lissue de la création de ceLSP, des messages de rafraîchissement RSVP TE devront être émis périodiquement afin demaintenir le LSP créé (soft-state protocol). - 25 -
  35. 35. Chapitre II : MPLS Traffic Engineering Nous allons résumer le processus détablissement des chemins avec lexemple de lafigure 2.8 : R1 R4 (10) L=18 R6 (6) L=implicit -null (1) R2 R7 L=42 (5) R8 (9) (7) L=21 (4) (2) R3 (8) L=10921 R5 (3) PATH RESV Figure 2.8 : Path et Resv messages, lors de létablissement de chemin Supposant que R1 a déjà réalisé sa procédure CSPF et a déjà décidé des besoins en bandepassante quil veut réserver le long du chemin (R1àR2àR3àR5àR6àR7) : (1) R1 envoie un Path message à R2. R2 reçoit le Path message, vérifie le format du message et la disponibilité de la bande passante demandée par R1. Sil y a un problème, R envoie un message derreur (PathErr) vers R Si tout se passe bien, on 2 1. passe à létape (2) (2) R2 envoie un Path message à R3. R3 fait les mêmes vérifications que dans létape(1) (3) R3 envoie un Path message à R5. Réalisation des mêmes vérifications. (4) R5 envoie un Path message à R6. Réalisation des mêmes vérifications. (5) R6 envoie un Path message à R7. Réalisation des mêmes vérifications. (6) R7, étant le tunnel tail, envoie un Resv message à R6. Ce Resv message contient le label que R7 veut voir dans les paquets de ce tunnel. Puisque R est le tail, il envoie 7 un label= implicit-null=3. (7) R6 envoie un Resv message à R5 et indique quil veut voir un incoming label 42 dans les paquets de ce tunnel. Ceci veut dire que quand R reçoit le label 42, il enlève ce 6 label (à cause de limplicit-null) et envoie le paquet vers R7. (8) R5 envoie un Resv message à R3 et indique quil veut voir un incoming label 10921 dans les paquets de ce tunnel. Ceci veut dire que quand R reçoit un paquet de donnée 5 avec le label 10921, il le change (swapping) en 42 et envoie le paquet vers R6. - 26 -
  36. 36. Chapitre II : MPLS Traffic Engineering (9) R3 envoie un Resv message à R2, en signalant le label 21 (10)R2 envoie un Resv message à R1, en signalant le label 18 ;A ce stade, Le TE LSP est complètement établie entre R et R7. Le headend (R1) peut alors 1commencer à envoyer les données. • La maintenance des chemins Dun premier coup dœil, la maintenance des chemins et très similaire à létablissementdes chemins : chaque 30 secondes (Plus ou moins 50%), le headend envoie un Path messagepar tunnel. Si un routeur envoie quatre Path messages successifs et ne reçoit pas de Resvmessage correspondant, il considère la réservation supprimée et envoie un message dans lesens inverse indiquant que la réservation est supprimée.Cependant, il y a une chose importante à comprendre ici. Path et Resv messages sont tous lesdeux envoyés dune façon indépendante et asynchrone dun voisin à un autre. Si on regardeencore une fois la figure 2.8, chaque 30 secondes, R envoie un Path message à R2 pour la 1réservation quil a effectué. Et chaque 30 secondes, R envoie un Resv message à R1 pour la 2même réservation. Cependant, les deux messages ne sont pas connectés. Un Resv messageutilisé pour rafraîchir une réservation existante nest pas envoyé en réponse à un Pathmessage, comme cest le cas de ICMP Echo Reply qui est envoyé en réponse à un ICMP EchoRequest. On na pas de comportement ping/ACK avec Path et Resv messages.3.2.2 La suppression des chemins La suppression des chemins est une procédure assez simple. Si un nœud décide quuneréservation nest plus nécessaire dans un réseau, il envoie un PathTear le long du mêmechemin que le Path message a suivi et un ResvTear le long du même chemin que le Resvmessage a suivi. ResvTear messages sont envoyés en réponse aux PathTear messages poursignaler que le tunnel tail a supprimé la réservation du réseau. Exactement comme les messages de rafraîchissement, PathTear messages nont pas àtraverser la totalité du chemin avant que leur effet ne prend place. Dans la figure 2.8, si R1envoie un PathTear à R2, R2 répond immédiatement par un ResvTear et puis envoie sonpropre PathTear au next hop. - 27 -
  37. 37. Chapitre II : MPLS Traffic Engineering3.2.3 La signalisation des erreurs De temps en temps, des problèmes peuvent avoir lieu dans le réseau (Bande passantenon disponible, boucle de routage, routeur intermédiaire ne prend pas en charge MPLS,message corrompu, création de label impossible, etc.). Ces erreurs sont signalées par PathErrou ResvErr messages. Une erreur détectée dans un Path message est traitée par un PathErrmessage, et une erreur détectée dans un Resv message est traitée par un ResvErr message.Les messages derreurs sont envoyés vers la source de lerreur ; le PathErr est envoyé vers leheadend, et un ResvErr est envoyé vers le tail.4 Constraint-based Routing over Label Distribution Protocol (CR-LDP) Des modifications ont été apportées au protocole LDP pour permettre laspécification du trafic. Ce protocole a été nommé CR-LDP (Constraint-based Routing overLabel Distribution Protocol) [4]. Lidée de ce protocole était dutiliser un protocole dedistribution de label déjà existant et de lui ajouter la capacité de gérer le Traffic Engineering. Sans entrer dans les détails de LDP, CR-LDP ajoute des champs à ceux déjà définisdans LDP, tel que "peak date rate" et "committed data rate". Le premier indique le débitmaximum avec lequel un trafic peut être envoyer via le TE LSP et le deuxième indique ledébit garanti par le domaine MPLS pour ce trafic. La gestion des réservations dans CR-LDPest très similaire à celle utilisée dans les réseaux ATM, Alors que RSVP TE utilise plutôt lemodèle de IntServ.4.1 Les messages CR-LDPIl y a quatre catégories de message CR-LDP : • Discovery messages : utilisés pour annoncer et maintenir la présence des LSR dans le réseau. Ceci est réalisé par lenvoie périodique de messages Hello. • Session messages : utilisés pour établir, maintenir et libérer des sessions entre des voisins LDP. • Advertisement messages : utilisés pour créer, changer et libérer des associations de FEC et LSP. - 28 -
  38. 38. Chapitre II : MPLS Traffic Engineering • Notification messages : utilisés pour véhiculer les informations de supervision. Il y a deux sortes de Notification messages : - Error notifications : utilisés pour signaler les erreurs fatales. Quand ces messages sont reçus, la session LDP est terminée et toutes les associations de labels correspondantes sont annulées. - Advisory notifications : utilisés pour véhiculer des informations sur la session LDP.4.2 Le fonctionnement de CR-LDP On va expliquer dune façon concise les étapes qui aboutissent à létablissement dunCR-LDP LSP. Pour cela, examinant la figure 2.9 : (1) (2) LABEL REQUEST (B,C) LABEL REQUEST (C) LSR A LSR B LSR C Ingress LABEL MAPPING (17) LABEL MAPPING (32) Egress (5) (4) (3) Figure 2.9 : Etablissement dun CR-LDP LSP (1) Ingress LSR A détermine quil a besoin détablir un nouveau LSP vers LSR C en passant par LSR B. Pour cela, LSR A envoie à LSR B un LABEL_REQUEST message avec lexplicit route (B,C) et le détail des paramètres du trafic nécessaire pour cette nouvelle route. (2) LSR B reçoit le LABEL_REQUEST message, réserve les ressources demandées, modifie lexplicit route dans le LABEL_REQUEST message et fait suivre le message à LSR C. Si nécessaire, LSR B peut réduire les réservations demandées dans le cas où les paramètres correspondant sont marqués négociables dans le LABEL_REQUEST message. (3) LSR C détecte que cest lui legress LSR. Il fait les mêmes activités de réservation et de négociation que LSR B. Il alloue un label pour le nouveau LSR et lenvoie à LSR B dans un LABEL_MAPPING message. Ce message contient aussi les détails des paramètres finaux du trafic pour cet LSP. - 29 -
  39. 39. Chapitre II : MPLS Traffic Engineering (4) LSR B reçoit le LABEL_MAPPING message, il finalise la réservation, alloue un label pour le LSP et met à jour sa table de labels. Ensuite, il envoie le nouveau label à LSR A dans un autre LABEL_MAPPING message. (5) Le même processus se réalise dans LSR A. Mais vu que LSR A est lingress LSR, il naura pas à allouer un label.Ainsi le nouveau LSR est établi et les données peuvent y transiter. Aujourdhui dans lindustrie, on trouve que Cisco et Jupiter favorise RSVP TE alorsque Nortel favorise CR-LDP. CR-LDP est un hard-state protocol : cest-à-dire quune fois unLSR est établi, il restera maintenu jusquà sa libération explicite. Ce qui nest pas le cas RSVPTE qui doit périodiquement entretenir ses LSP par des messages de signalisation (soft-stateprotocol). Cette différence permet à certain de dire que CR-LDP est plus scalable (résistant àlaugmentation de la taille du réseau), vu que dans le cas de RSVP TE, plus le réseau estétendue plus il sera encombré par des messages de rafraîchissement. Malgré ceci, RSVP TEparait être plus favorable à simposer comme protocole supportant le Traffic Engineering.Ceci peut sexpliquer par le fait que RSVP est plus ancien que CR-LDP et par conséquent plusmature et franc de bugs ; dautant plus que le constat quon a fait sur la scalabilité de ceprotocole est très discutable.Conclusion Au terme de ce chapitre, nous avons terminé létude théorique de la technologieMPLS: nous avons passé en revu son fonctionnement, ses principales composantes et nousavons mis laccent sur lapplication TE. Nous essayerons de montrer, dans les chapitressuivants, lintérêt et de MPLS et son apport pour un opérateur ou un fournisseur de service enterme de "Traffic Engineering". - 30 -
  40. 40. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TEIntroduction Le but de ce chapitre est de mettre en évidence les fonctionnalités de MPLS TE enutilisant la simulation comme moyen dévaluation. On va commencer par expliciter les paramètres sur lesquels on va se baser dans notreévaluation, à savoir les paramètres de Qualité de Service. Ensuite, on va présenterlenvironnement de simulation utilisé, pour enfin expliquer la simulation étudiée et procéder àl’analyse des résultats obtenus.1 La qualité de service La qualité de service (QoS) [5] décrit le niveau de performance attendu duneapplication, dun serveur, dun réseau ou de tout autre dispositif. Par exemple pour uneapplication, les paramètres principaux à envisager pour évaluer la QoS sont en général labande passante, le taux de perte en paquets, le délai de bout en bout et la gigue [6].1.1 Bande Passante (Bandwidth) Terminal A Terminal B 10Mbps 128 kbps 100 Mbps 512 kbps Figure 3.1 : Illustration du concept de bande passante Dans lexemple ci-dessus, La bande passante que peut utiliser le Terminal A pourcommuniquer avec le Terminal B est simple à calculer : cest la bande passante que peut offrirle plus faible des liens soit 128 kbps. Ceci dans le cas où le réseau est vide. Il en est autrementsil existe plusieurs flux qui traversent le réseau. Le calcul de la bande passante est dautantplus complexe quil y a de considérations à respecter (capacité du lien, nombre de flux et leursdemandes respectives, priorité, réservation préalable, etc.) - 31 -
  41. 41. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE1.2 Perte en paquets (Paquet Loss) Généralement, la perte de paquets a lieu lorsque le routeur manque despace dans lebuffer dune interface : ainsi, lorsque la file dattente de sortie dune interface particulière estsaturée, les nouveaux paquets qui seront dirigés vers cette interface vont être rejeter.Les routeurs peuvent rejeter un paquet pour dautres raisons, par exemple : • Le CPU (Central Processing Unit) est congestionné et ne peut p traiter le paquet (la as file dattente dentrée est saturée) ; • Le routeur détecte une erreur dans le paquet (Paquet corrompu) ; • Le routeur rejette les paquets les moins prioritaires en cas de congestion dans le réseau.Dautres facteurs peuvent constitués des causes pour la perte de paquets tel que : • Lerreur de routage ; • La fiabilité du media de transmission.La perte peut sexprimer en pourcentage de paquets perdus par rapport aux paquets émis, outout simplement en nombre de paquets perdus par unité de temps.1.3 Délai de bout en bout (End to End Delay) Terminal A Terminal B Délai de Délai de Délai de Délai de propagation propagation propagation propagation Délai de traitement et Délai de traitement et Délai de traitement et de mise en file dattente de mise en file dattente de mise en file dattente Figure 3.2 : Illustration du concept de délai de bout en bout Le délai de transmission de bout en bout est le temps écoulé entre lémission du paquetet sa réception à larrivée. La figure 3.2 illustre limpacte qua le r éseau sur le délai de bout enbout des paquets transmis dun Terminal A vers un Terminal B. Chaque saut dans le réseauajoute un délai supplémentaire dû aux trois facteurs suivant : • Délai de propagation : Cest le temps que prend la transmission dun bit via le média de transmission (paire torsadée, fibre optique, voie radio, etc.) - 32 -
  42. 42. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE • Délai de traitement : Cest le temps que consomme un routeur pour prendre un paquet de linterface dentrée et le mettre dans la file dattente de linterface de sortie. Ce délai dépend de plusieurs facteurs tel que : - La vitesse du CPU ; - Lutilisation du CPU ; - Le mode de commutation IP (routage IP classique, utilisation de la commutation de label, etc.) ; - Larchitecture du routeur ; - La taille du paquet. • Délai de mise en file dattente : Cest le temps que le paquet passe dans la file dattente de sortie du routeur. Il dépend du nombre et de la taille des paquets déjà dans la file et de la bande passante de linterface. Il dépend aussi du mécanisme de file dattente adopté. Le délai de bout en bout est la somme de tous les délais (propagation, traitement et filedattente) à travers le chemin parcouru depuis la source jusquà la destination. Le délai depropagation est fixe (ne dépend que du média de transmission), alors que le délai detraitement et le délai de mise en file dattente sont variables (dépendent du trafic).1.4 Gigue (Jitter) C’est la variation (en ms) du délai entre les paquets consécutifs (Voir Figure 3.3). Laprésence de gigue dans les flux peut provenir des changements dintensité de trafic sur lesliens de sorties des commutateurs. Plus globalement, elle dépend du volume de trafic et dunombre déquipements sur le réseau. La gigue affecte les applications qui transmettent les paquets à un certain débit fixe etsattendent à les recevoir au même débit (par exemple : voix et vidéo). - 33 -
  43. 43. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE Emission Réception Gigue Figure 3.3 : Illustration du concept de la gigue1.5 Les exigences des différentes applications IP en terme de QoS Les problèmes de qualité de service sont pratiquement inexistants en téléphoniecommutée ; puisque cette dernière utilise la commutation de circuit qui consiste enlétablissement dune connexion physique de bout en bout, dédiée à chaque paire démetteursrécepteurs. Dans le monde IP, La QoS est un passage obligatoire. Car contrairement au réseautéléphonique commuté, les réseaux IP véhiculent une multitude dapplications qui différentpar leurs exigences en terme de QoS. Ces applications concourent pour se partager unequantité de ressources limitée offerte par le réseau. Cest pourquoi il est primordial de pouvoircerner les besoins nécessaires (le besoin minimum) mais aussi suffisants (pas de gaspillage)pour chaque type particulier dapplication en terme de QoS. Bande Sensibilité à Sensibilité au Sensibilité à Type dapplication passante la perte en délai la gigue requise paquets Voix (VoIP) Elevé Moyenne Elevé Elevé Vidéo Elevé Moyenne Elevé Elevé (Vidéoconférence) Application interactive Non Moyenne Elevé Moyenne (HTTP, jeux en ligne) importante Non Best effort (FTP) Moyenne Elevé Faible importante Non Background (mail) Faible Elevé Faible importante Tableau 3.1 : Les exigences des différentes applications IP en terme de QoS - 34 -

×