Your SlideShare is downloading. ×
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
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
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
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Mpls foudhaili oussama

1,278

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,278
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
134
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. "Là où tout finira, là où tout commencera!" Confucius
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 -
  • 44. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE Dans le tableau ci-dessus, il est intéressant de remarquer - à titre dexemple - que lesapplications temps réel (voix, vidéo) sont très sensibles au délai et à la gigue, ce qui nest pasle cas des applications orientées donnée. En contre partie, les applications temps réel sontassez tolérantes aux pertes alors quune application comme mail ou FTP ne tolère pas du toutles pertes.2 Lenvironnement de simulation2.1 Lintérêt d’utiliser un simulateur Les mécanismes utilisés dans les réseaux IP (protocole de routage, file dattente et dansnotre cas MPLS) doivent être évalués afin de mesurer les performances des stratégies utiliséeset de tester leur fiabilité. Lutilisation dun réseau réel dans une évaluation est difficile etcoûteuse, en outre de telles évaluations ne donnent généralement pas des résultatssignificatifs. Le réseau réel noffre pas la souplesse de varier les différents paramètres delenvironnement et pose en plus le problème dextraction de résultats ; cest pour cela que lamajorité des travaux dévaluation de performances utilisent le principe de simulation vu lesavantages quil offre. En effet, la simulation permet de tester les protocoles sous une variété deconditions. Pour notre projet, nous avons choisi de travailler avec « Network Simulator 2 (NS2) ».2.2 Présentation de NS2 NS ou "Network Simulator" [7] est un simulateur de r éseau IP, à évènements discrets,orienté objet. C’est un projet piloté par l’ISI (University of Southern California, USA). Il estgratuit, open source, portable et mis à jour régulièrement. Il tourne sur plusieurs distributionsd’UNIX et de Windows. C’est le simulateur le plus utilisé dans la communauté scientifique. Il permet àl’utilisateur de simuler plusieurs communications entre les différents nœuds d’un réseau. Il estbien adapté pour simuler la circulation de paquets dans les réseaux commutés. Il estprincipalement utilisé pour tester des algorithmes de file d’attente, de contrôle de congestion,des protocoles de transport, des protocoles de routage, le multicast et la mobilité. - 35 -
  • 45. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE La version 1.0 de ce simulateur a été initialement développée au Laboratoire Nationalde Lawrence Berkeley (LBNL). Il fait actuellement partie du projet VINT (VirtualInterNetwork Testbed) sous lequel la deuxième version (NS2) est sortie.Le projet VINT est dirigé par l’université de Californie du sud et est financé par le DARPA encollaboration avec Xerox PARC et LBNL. Il est utilisé par plusieurs groupes de travailcomme l’IETF pour évaluer les protocoles en cours de normalisation.2.3 Fonctionnement de NS2 NS2 est un outil de recherche très util pour le design, la validation et lévaluation desprotocoles. Le simulateur utilise le langage orienté objet OTCL dérivé de TCL pour la descriptiondes conditions de simulation sous forme de scripts (Voire figure 3.4). Dans le script,lutilisateur fournit la topologie du réseau, les caractéristiques des liens physiques, lesprotocoles utilisés, le type de trafic généré par les sources, les événements, etc.Si le script écrit en OTCL permet une utilisation (édition, modification des simulations) faciledu simulateur, les routines -quant à elles- sont écrites en C++ pour avoir une plus grandepuissance de calcul. Ces routines incluent entre autres plusieurs types de protocoles, de filesdattente et dalgorithmes de routage. - 36 -
  • 46. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE Script OTCL (description de scénario) Animation Nam : - Topologie Visualisation des - Caractéristiques des nœuds différents évènements - Caractéristiques des liens du scénario de la - Protocoles utilisés simulation. - Type de trafic généré - Evènements (envoie de paquet, rupture de liens, changement de mode de routage, etc.) - Etc. Simulation Fichier trace :Code en C++ (description des routines) Description textuelle des- L’implémentation des algorithmes évènements relatifs à la (de routage, de file d’attente, …) simulation.- L’implémentation des modélisations des liens physiques- L’implémentation de la procédure d’encapsulation- Etc. Filtrage, courbe et analyse des résultats : (AWK, XGraph, etc.) Figure 3.4 : Les étapes d’une simulation sur NS2 Avant de lancer une simulation, on introduit les paramètres de la simulation dans NSgrâce aux scripts TCL. Les paramètres consistent notamment en le nombre de n œud, les liens,les protocoles mis en œuvre, les différents événements qui vont survenir, etc. Cette phase esten fait une phase de description du scénario de simulation. Les outputs des simulations sont des fichiers textes qu’on appelle fichiers trace. Cesfichiers sont structurés en entrées. Chaque entrée correspond à une action effectuée par unnœud (envoie de paquet, rejet de paquet, mise en file dattente, réception dun paquet). A titredexemple, soit lentrée suivante : r 5.213 2 1 cbr 500 ------- 3 3.0 0.0 21 305 Cette entrée traduit la réception (r) à linstant (5.213)s dun paquet de type (cbr) detaille (500) octets, de numéro didentité (305), de numéro de s équence (21), appartenant auflux (3), transitant entre les n œuds (2) et (1), ayant pour adresse source (3.0) (adresse.port) etpour adresse destination (0.0). - 37 -
  • 47. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE Ces fichiers doivent être traités pour pouvoir calculer les valeurs de bande passante,perte, délai et gigue relatives au scénario en question. Par exemple, pour calculer le taux deperte, il suffit de compter les entrées commençant par « d » (drop=rejeté) et les entréescommençant par « r » (received=reçu), et ainsi extraire le taux de perte. Ce traitement a étéréalisé par le langage de traitement des fichiers : AWK. Enfin, le traçage des courbes a été réalisé par Xgraph. Par ailleurs, le simulateur permet la création dun fichier danimation permettant devisualiser la simulation sur une interface graphique appelée NAM.2.4 Les modifications à apporter à NS2 Les simulations ont été faite sur un processeur Intel Pentium III à 600MHz, 128Mo deRAM, exécutant Linux Red Hat 9.0. La version utilisée de NS est 2.26. Cette version ne supporte pas les protocoles relatifsà MPLS. On a alors dû implémenter un ensemble de modules en extension à NS2.26 pourfaire de sorte que ce dernier puisse simuler les fonctions MPLS.Les modules ajoutés sont les suivants : • MPLS Network Simulator (MNS v2.0) Ce module [10] est développé par Gaeil Ahn et Woojik Chun, Department of Computer Engineering, Chungnam National University, Koreo. Il permet à NS2 de prendre en charge des routines relatives à MPLS tel que : la manipulation de label, la commutation de label, etc. • Weighted Fair Queuing (WFQ) Ce module [11] est développé par Paolo Losi et mis à jour par Sayenko Alexander, Telecommunication laboratory, MIT department, University of Jyvaskyla, Finland. - 38 -
  • 48. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE Il permet de différencier les flux en attribuant à chaque trafic un poids (weight) qui reflétera son niveau de priorité. • RSVP/ns Ce module [12] est développé par Marc Greis, Computer Science Department IV, University of Bonn. Cest une implémentation du protocole de réservation de ressource RSVP. • RSVP-TE/ns Ce module [13] est développé par Christian Callegari et Fabio Vitucci, Dept. of Information Engineering, University of Pisa, ITALY. Cette implémentation contient la prise en charge des fonctions de Traffic Engineering pour le protocole RSVP. • le compilateur GNU C/C++ (GCC 2.95) Le compilateur GCC est installé par défaut avec Linux. Cependant, dans la plupart des cas la version qui est livrée avec la distribution Linux est soit GCC 2.96, soit GCC 3.x. Le problème cest que la première présente beaucoup de bugs et la deuxième a subi tellement de modifications quelle ne supporte plus les modules quon va implémenter dans NS2. Ceci nous a conduit à changer la version du compilateur par défaut par la version 2.95.3.2.5 Avantages, limites et difficultés de NS2 Comme tout outil de simulation, NS2 permet ’étude de ’existant, la conception, la l lvalidation et l’évaluation de performances et ceci dans le domaine des protocoles etmécanismes réseau. C’est un simulateur extrêmement flexible. NS2 permet l’étude des casdifficiles à reproduire dans la réalité. Il offre la souplesse de pouvoir varier aisément unemultitude de paramètres du réseau (ce qui n’est pas le cas si on simule sur un réseau réel).Donc, par rapport à l’expérimentation sur un réseau réel, NS2 permet un gain de temps etd’argent. - 39 -
  • 49. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE D’un autre côté, NS2 souffre des inconvénients des simulateurs tel que lasimplification et l’abstraction du monde réel, la difficulté (voire l’impossibilité) de testercertains aspects, et la puissance de calcul requise qui croit exponentiellement avec lacomplexification du système simulé. De plus, NS2 souffre de l’état primitif aussi bien de sesoutils de collecte et traitement des résultats que de son interface graphique. Les concepteursde NS2 ne manquent pas de mettre en garde les utilisateurs sur laspect non achevé de cesimulateur. Il ne sagit pas dun produit fini, de nouveaux bogues sont souvent trouvés etdautres constamment introduits par les programmeurs. Finalement, on remarque souvent desproblèmes dincompatibilité entre les implémentations de NS, les modules développés pourNS et les versions de linux. Dans le cas de notre projet, cest surtout les deux derniers points qui ont présenté unedifficulté de taille pour lavancement de notre travail dautant plus que la documentationmanque sévèrement : généralement, les modules qui sont développés pour NS2 sont en étroitedépendance avec les systèmes sur lesquels ils ont été développés initialement. De ce fait, il afallu constamment faire face à des problèmes dincompatibilité et de réadaptation des modulespour quils puissent fonctionner sur la machine quon utilise. On a dû passer par une série detest (implémentation de plusieurs modules, introduction de plusieurs modifications, test deplusieurs combinaisons) et consulter une multitude de documentation concernant lamanipulation du système dexploitation. Le recours aux forums de discussion et laconsultation des auteurs des modules par mail ont été souvent les seuls moyens de surmontercertains problèmes. Létablissement dune procédure de prise en charge de MPLS RSVP TE par NS2 aconsommé beaucoup deffort et de temps. Et bien quelle ne constitue quune étapepréliminaire pour notre projet (à savoir lévaluation des performances de MPLS TE), elle acomme même été très enrichissante du point de vu expérience dans le débuggage et lamanipulation de Linux.3 Simulation des fonctionnalités de MPLS TE3.1 Le scénario de simulation On se propose de mettre en évidence les fonctionnalités de MPLS TE en utilisantRSVP TE comme protocole de distribution de label. - 40 -
  • 50. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE Pour cela, on a adopté une topologie et un scénario qui permet dexpliciter le plus clairement possible le concept de TE. La topologie est constituée de 13 nœuds connectés comme indiqué sur la figure 3.5. Figure 3.5 : La topologie de simulation visualis ée par NAM Le scénario est le suivant : Les nœuds 0, 1 et 2 sont configurés pour être des générateurs de trafic. Les nœuds 11, 12 et 13 sont configurés pour recevoir le trafic, lanalyser et ainsi pouvoir renseigner sur les paramètres à mesurer (Bande passante, Perte, Délai, Gigue). Tous les autres nœuds (3..10) sont des LSR configurés pour supporter le protocole RSVP TE. Enfin, tous les liens de la topologie sont dotés dune bande passante de 2Mbps. Les caractéristiques des flux qui vont traverser cette topologie sont explicitées dans le tableau 3.2 :Nœud Nœud Taille des Débit Couleur dans Type du traficsource destination paquets (octet) (Mbps) lanimation NAM 0 11 500 1.8 Temps réel (TR) Bleu 1 12 500 1.3 Haute priorité (HP) Vert 2 13 500 0.6 Best Effort (BE) Rouge Tableau 3.2 : Les flux considérés dans la simulation Le trafic temps réel est généralement un trafic voix ou vidéo. Le trafic haute priorité peut véhiculer par exemple une application interactive. Quant au trafic best effort, il peut englober les services mail, transfert de fichier (FTP), etc. - 41 -
  • 51. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TELe timing de la simulation est détaillé dans le tableau 3.3 : Instant (s) Evénement LSP 0 Début de la simulation 0.2 Début de génération des trafics par les nœuds 0, 1 et 2 Activation de la fonction TE pour le nœud 0 6 0_3_4_10_11 (établissement dun LSP) Activation de la fonction TE pour le nœud 1 6 1_5_6_7_9_10_12 (établissement dun LSP) Activation de la fonction TE pour le nœud 2 7 2_5_6_7_8_10_13 (établissement dun LSP) Désactivation de la fonction TE pour le nœud 1 9 (Libération du LSP) Réactivation de la fonction TE pour le nœud 1 11 (rétablissement du LSP) Provocation dune rupture dans le lien entre les noeuds 7 et 8. Ce qui provoque une procédure automatique de 13 2_5_6_7_9_8_10_13 reroutage du trafic venant du nœud 2 et létablissement dun nouveau LSP contournant ainsi le lien rompu 15 Fin de la simulation Tableau 3.3 : Timing de la simulation3.2 Résultats de la simulation et interprétations La simulation décrite ci-dessus a permis de tracer des courbes relatives à chacun destrois trafics mis en œuvre : • Le trafic temps réel entre les nœuds 0 et 11 • Le trafic haute priorité entre les nœuds 1 et 12 • Le trafic best effort entre les nœuds 2 et 13 Pour chacun de ces flux, on va mesurer la variation par rapport au temps des quatreparamètres de QoS à savoir : la bande passante, le taux de perte, le délai de bout en bout et lagigue.On rappel quon va utiliser les abréviations suivantes (voir tableau 3.2) : • TR : Le flux Temps Réel • HP : Le flux Haute Priorité • BE : Le flux Best Effort - 42 -
  • 52. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE3.2.1 "Bande passante" et "Taux de perte en paquets" Temps réel (TR) Haute priorité (HP ) Best effort (BE) Figure 3.6 : Bande Passante Temps réel (TR) Haute priorité (HP ) Best effort (BE) Figure 3.7 : Taux de paquets perdus - 43 -
  • 53. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE Pour commenter ces courbes, on va procéder par intervalles de temps. Chaqueintervalle de temps correspondant à un événement particulier (Voir Tableau 3.3). • Lintervalle [0.2s .. 6s] Figure 3.8 : Situation du trafic entre les instants 0.2s et 6s On rappelle que la demande est de 1.8 Mbps pour le flux TR, 1.3 Mbps pour le HP et0.6 Mbps pour le BE. On remarque quà la stabilité, TR a reçu une bande passante de 1.2Mbps, HP a reçu 0.6 Mbps et BE a reçu 0.2 Mbps (Voir figure 3.6). Ceci correspond à unroutage classique avec prise en compte des priorités respectives des flux. En effet, le protocolede routage a choisi de faire passer tous les flux par le plus court chemin (5_3_4_10) (Voirfigure 3.8). On remarque que la somme des bandes passantes assignées au trois flux est égaleà 2 Mbps soit la capacité maximale du lien de transmission. La bande passante demandéeétant plus grande (3.7 Mbps), cest pourquoi on remarque une saturation de la file dattentedans le nœud 3 (Voir figure 3.8). La file dattente est la cause essentielle des pertes en paquets.Les pourcentages de perte sont assez grandes (TR : 33% ; HP : 53% ; BE : 66%) (Voir figure3.7). • Lintervalle [6s .. 7s] Figure 3.9 : Situation du trafic entre les instants 6s et 7s - 44 -
  • 54. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE A linstant 6, RSVP TE établie un LSP 3_4_10 pour le flux TR et un LSP 5_6_7_9_10pour le flux HP. Ainsi dans la courbe de bande passante on remarque que ces deux flux ontreçu la totalité du débit quils sollicitent. Ceci induit évidement à lannulation de leur taux deperte (Voir Figure 3.7). Le flux BE entrent en compétition pour le même média avec le fluxTR, cela dit, il ne reçoit que ce qui reste de la bande passante (0.2 Mbps à la stabilité) vu quesur ce lien, TR a fait une réservation préalable et est donc prioritaire. Le taux de perte relatif àBE reste bien évidemment élevé. Entre linstant 6 et 7, on remarque un pic au-delà de 1.8 Mbps pour la bande passante deTR. Le débit supplémentaire provient de la file dattente qui se vide en laissant la priorité auxpaquets relatifs au TR. • Lintervalle [7s .. 9s] Figure 3.10 : Situation du trafic entre les instants 7s et 9s A linstant 7, RSVP TE établie un LSP 5_6_7_8_10 pour le flux BE. Ainsi BE, bienque partageant une partie du chemin avec HP, a pu satisfaire totalement son exigence enbande passante et avoir un taux de perte nul. Il est intéressant ici dobserver la différence entre lacheminement des paquets utilisantle routage classique (Figure 3.8) et lacheminement des paquets utilisant le TrafficEngineering (Figure 3.10). Cette simulation montre dune façon explicite que le routageclassique ne permet pas une utilisation optimale des liens du réseau : puisque on observe unesur-utilisation de certains liens et une sous utilisation dautres liens. Ceci provient du fait queles protocoles de routage classiques sont incapables de choisir un chemin autre que le cheminle plus court. Le Traffic Engineering apporte une solution pratique pour ce problème ;puisque, comme cest démontré par cette simulation, TE permet un équilibrage de chargeoptimal sur tous les liens du réseau et une satisfaction totale des exigences des trois trafics enterme de bande passante. - 45 -
  • 55. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE Finalement, entre les instants 7 et 8 et pour le flux BE, on remarque un pic dépassant 0,6Mpbs. Ce débit supplémentaire provient de la file dattente du n œud 3 qui contient encore despaquets BE. • Lintervalle [9s .. 11s] (1) (2) Figure 3.11 : Situation du trafic entre les instants 9s et 11s A linstant 9, on réalise une libération du LSP relatif au trafic HP. Ce flux subit alors unroutage classique et empreinte par conséquence le chemin le plus court : soit 5_3_4_10 (Voirfigure 3.11 (1)). Sur ce chemin, le flux HP nest servi quen deuxième lieu par rapport à TR vuque ce dernier a réservé 1.8Mbps sur ce lien. HP se contente alors des 0.2 Mbps qui reste(Voir figure 3.6). En résultat, on remarque une augmentation de 84% de taux de perte pourHP, schématisé par un débordement de la file dattente dans la figure 3.11 (2). • Lintervalle [11s .. 13s] Figure 3.12 : Situation du trafic entre les instants 11s et 13s En réactivant le TE pour HP on retrouve le rééquilibrage des charges sur les liens duréseau et un vidage progressif de la file dattente dans le n œud 3 (Ce qui explique encore unefois le pic entre les instants 11 et 12 pour le trafic HP (Voir figure 3.6). - 46 -
  • 56. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE • Lintervalle [13s .. 15s] (1) (2) Figure 3.13 : Situation du trafic entre les instants 13s et 15s La rupture du lien entre les nœuds 7 et 8 a provoqué une perturbation de 0.75s dans labande passante (Voir figure 3.6) et une augmentation conséquente du taux de perte (Voirfigure 3.7). Juste après, il y a eu établissement dune nouvelle LSP (Voir figure 3.13 (2))permettant de nouveau un équilibrage optimal des charges sur le réseau. En attendant que RSVP TE termine la procédure de reroutage, le flux BE a subi unroutage classique (Voir figure 3.13 (1)). Cette simulation a permis ainsi de mettre en évidence la robustesse de MPLS TE faceaux pannes. - 47 -
  • 57. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE3.2.2 "Délai de bout en bout" et "Gigue" Temps réel (TR) Haute priorité (HP ) Best effort (BE) Figure 3.14 : Délai de bout en bout Figure 3.15 : Gigue relatif au trafic TR - 48 -
  • 58. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE Temps réel (TR) Haute priorité (HP ) Best effort (BE) Figure 3.16 : Gigue re latif au trafic HP Figure 3.17 : Gigue relatif au trafic BE - 49 -
  • 59. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE • Lintervalle [0.2s .. 6s] Dans cet intervalle le délai est presque identique pour les 3 flux (TR : 90ms ; HP,BE :100ms). TR profite dun débit meilleur parce quil est privilégié dans la file dattente. La gigue est stable (RT : jusquà ms, HP : jusquà 2.2ms, BE : jusquà 1.0ms). Laprésence de la gigue est due essentiellement à la file dattente dans le nœud 3. Elle est trèsfaible pour TR, ce qui traduit sa priorité dans la file par rapport aux autres flux. Elle est assezconstante pour lensemble des trafics, ce qui traduit la régularité de la satisfaction des troisflux. Figure 3.18 : Zoom relatif à la courbe de gigue • Lintervalle [6s .. 7s] Létablissement de LSP pour TR et HP a f que leur délai de bout en bout sest nettement aitamélioré (amélioration de 30ms pour HB et de 40ms pour TR (voir figure 3.14)). Le flux BEvoit sont délai augmenter exponentiellement vu quil empreinte un chemin réservé par TR. En ce qui concerne HP, lamélioration de la gigue est nette (0.1ms au lieu de 2.2ms). Onpeut même dire que ce trafic ne présente pas de gigue, puisque il est seul sur le chemin quilemprunte. La gigue relative à BE atteint 5ms, vu que TR est prioritaire par rapport BE.Lamélioration du délai relatif à TE na pas empêché sa gigue daugmenter de 0.2ms. Mais unetelle augmentation na pas dincidence sur les applications temps réel. • Lintervalle [7s .. 9s] Létablissement dun LSP pour le flux BE a amélioré son délai qui est devenu égal à celuide HP (70ms), puisque ces deux trafics empruntent des LSP de même longueur. - 50 -
  • 60. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE Figure 3.19 : Zoom relatif à la courbe de délai entre les instant 8.5s et 8.85s On remarque sur la courbe des délais la présence dune petite variation périodiquerelatif aux flux HP et BE (Voir figure 3.19). Ceci est dû au fait que ces deux traficsempruntent des chemins sécants. Cest ce qui explique la légère augmentation de la giguerelative à HP (jusquà 0.4ms) Pour le trafic TR, on remarque que la gigue reste la même jusquà linstant 7.5, vu que lafile dattente du nœud 3 contient encore des paquets BE. A partir de 7.5, la file devient vide etla gigue disparaît pour le trafic TR. • Lintervalle [9s .. 11s] La désactivation du LSP de HP fait quil est routé s le même chemin que TR. Or TR a urréservé sont chemin donc il est prioritaire. Cest pourquoi son délai est resté le même. Cela dit,la courbe de délai relative à TR nest plus constante mais oscille légèrement autour de samoyenne (Voir figure 3.14). Ceci est dû au partage du média avec le flux HP. Il en résulte uneaugmentation faible de la gigue de TR (0.3ms).HP nest servi quen dernier lieu. Son délai augmente alors exponentiellement pour atteindre460ms, et sa gigue se détériore pour atteindre 0.9ms. La gigue du trafic BE sest bien sûr améliorée puisque BE utilise seul le média. • Lintervalle [11s .. 13s] Le rétablissement du LSP de HP a rétabli les paramètres à leur état initial. • Lintervalle [13s .. 15s] Jusquà linstant 13,2s, BE observe une augmentation brusque du délai et de la gigue. Ceciest dû à la rupture du lien entre les nœuds 7 et 8 et au temps que prend la procédure dereroutage (recherche et établissement dun nouveau LSP optimal). - 51 -
  • 61. Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE Cette panne a profité pour HP dont la gigue sest améliorée pendant ces 0.2s. Le contrairesest produit pour TR qui a dû partager les liens quil utilise avec BE pendant la durée dereroutage. A partir de linstant 13.2, on observe une re-stabilisation des délais avec une augmentationde 10ms pour le flux BE vu que le nouveau LSP est plus long. Cette augmentation nest pashandicapante surtout que ce trafic est un Best Effort. Il est intéressant de remarquer que, durant toute la période de simulation, la gigue relativeau flux TR ne dépasse jamais 0.3ms. Ceci est très important pour un trafic temps réel (voix,vidéo). HP et BE atteignent parfois les 5ms de gigue mais ça na pas grande importance vu lanature de leurs applications.Conclusion Les simulations que nous avons réalisées ont mis en évidence le besoin dintégrer desmécanismes aux réseaux IP actuels pour pouvoir supporter les trafics multiservice et respecterles exigences propres à chaque type dapplication. MPLS TE est une solution qui sest montéeefficace et surtout simple à mettre en œuvre et très souple à manipuler. Elle permet de réaliserun équilibrage de charge sur lensemble du réseau et de prendre des décisions de re-routage ;ce qui se traduit par une utilisation plus optimale des ressources et une satisfaction plusgrandes des demandes des applications. - 52 -
  • 62. Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom" Chapitre IV : Evaluation des performances de MPLS TE sur le backbone de "Tunisie Télécom"Introduction On a déjà évoqué les avantages économiques quimplique lexploitation dun seulréseau pour plusieurs applications, et le gain qui pourra résulter du remplacement de lacommutation de circuit par la commutation de paquet. En suivant cette logique, Tunisie Télécom sest fixé le but davoir (dans le court/moyenterme) un réseau national unique pour véhiculer à la fois le trafic voix (à ce jour réalisé par unréseau à commutation de circuit) et le trafic de donnée (réalisé par la commutation de paquetet/ou de cellule). Ceci vient en conformité avec la logique de baisse des tarifications des Télécom. Deplus, migrer vers un tel réseau permettra doffrir une infrastructure plus encourageante àlinformatisation des entreprises et des particuliers. Ce qui contribuera à linstauration de la"Société de lInformation". On a vu dans le chapitre III quil est inévitable de passer par le "Traffic Engineering"pour optimiser lutilisation dun réseau afin quil soit apte à véhiculer du multiservice. Cestpourquoi, dans ce chapitre, on va essayer dévaluera lapport de la technologie MPLS TE surle backbone de Tunisie Télécom, ceci en utilisant la simulation sur NS2 comme outil détude.1 Description du backbone MPLS de Tunisie Télécom1.1 Définition de Backbone Un backbone est un ensemble dartères longues distances, à très haut débit detransmission, qui relient les principaux nœuds dun réseau étendu. Le backbone constitue lecœur du réseau, sur lequel des liaisons de plus faibles capacités de transmission sontraccordées. Ces liaisons servent à interconnecter des réseaux plus petits (internes à une - 53 -
  • 63. Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom"entreprise ou à une région). On peut faire lanalogie des petits réseaux se rattachant à unbackbone, avec des rivières qui viennent grossir le cours dun fleuve. Les liens qui forment le backbone sont constitués majoritairement de câbles à fibresoptiques installés sous les océans et sur les continents. On distingue les réseaux backbone nationaux (échelle dun pays), régionaux (échelledun groupe de pays) ou mondiaux (échelle de la planète). Dans notre cas, on sintéressera aubackbone national de Tunisie Télécom.1.2 Structure du backbone de Tunisie TélécomLe backbone quon va utilisé comme base pour nos simulations est le suivant : 18 LER 9 LSR Figure 4.1 : La structure du backbone de Tunisie TélécomIl est constitué de : • 9 LSR : – Quatre se trouvent dans le grand Tunis et plus précisément à Kasbah, Hached, Belvédère et Ouardia ; – Cinq sont dans les villes de Sfax, Sousse, Béja, Kairouan et Gabes. • 18 LER : – Neuf sont co-localisés avec les LSR ; – Neuf sont à Marsa, Ariana, Menzeh, Ben Arous, Bardo, Bizerte, Nabeul, Moknine et Gafsa. Cette architecture ne fait pas partie du cahier des charges de notre projet. Comme on peut le constater, chaque LSR est co-localisé avec un LER. Pour lacommodité de la représentation, on schématisera chaque couple LSR/LER co-localisé par unseul routeur. - 54 -
  • 64. Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom"La figure 4.2 montre la disposition géographique du backbone. Grand Bizerte Tunis Nabeul Béja Sousse Moknine Kairouan STM-4 LER Sfax 2 STM-4 LER/LSR STM-16 Gafsa Gabés Figure 4.2 : La disposition géographique du backbone de Tunisie TélécomPour mieux apprécier cette topologie, on va plutôt considérer la disposition de la figure 4.3 : Marsa Ben Arous Nabeul Bizerte Moknine Ouardia Béja Hached Sousse Menzeh Belvédère Sfax Kairouan Kasbah Gabès Ariana Bardo Gafsa Figure 4.3 : Backbone de Tunisie Télécom - 55 -
  • 65. Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom"Le backbone contient 3 types de liens : • STM-4 : format SDH de transmission sur fibres optiques avec une bande passante de 622.08 Mbps ; • 2 STM-4 : format SDH de transmission sur fibres optiques avec une bande passante de 1244.16 Mbps ; • STM-16 : format SDH de transmission sur fibres optiques avec une bande passante de 2488.32 Mbps. Chacun des 18 nœuds MPLS du backbone reçoit un "flux voix" et un "flux donnée". Letableau 4.1 illustre les capacités des liens raccordés au backbone selon le type de trafic quilsvéhiculent : Capacité du lien dédié au Capacité du lien dédié au Site trafic "Voix" (Gbps) trafic "Donnée" (Gbps) Ariana 1 2 Bardo 1 3.1 Béja 1 1.1 Belvédère 2 2 Ben Arous 2 5 Bizerte 1 1.6 Hached 2 2 Kairouan 1 1.1 Kasbah 2 1.1 Marsa 2 1 Menzeh 1 2 Moknine 1 1 Nabeul 2 3.3 Ouardia 2 2 Sfax 2 4.9 Sousse 2 3.5 Gabés 1 1 Gafsa 1 0.9 Tableau 4.1 : Descriptif des liens raccordés au backbone - 56 -
  • 66. Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom"2 Simulation et résultats2.1 Scénario de la simulation Afin dévaluer lapport de la technologie MPLS TE sur le backbone de TunisieTélécom, Nous avons procédé à limplémentation de la topologie sur NS2 (Voir Figure 4.4). Figure 4.4 : le backbone tel que généré par NS2La modélisation des distances : dLa transmission des données sur fibre vérifie la loi : c = tAvec c : célérité = 3 108 m/s d : longueur de la fibre t : délai de propagation Ainsi, pour avoir 1ms de délai de propagation, il faut 300Km de fibre. Or dans lebackbone étudié, es deux nœuds les plus éloignés et qui sont directement liés sont à 406Km l(Hached-Gabés). Etant donnée que le délai de bout en bout est généralement de lordre deplusieurs dizaines de ms, le délai de propagation (qui constitue une des composantes du délaide bout en bout) peut être négligé dans la simulation. Donc, au niveau du territoire national,les distances nont pas grande influence sur le délai de bout en bout.Description du trafic simulé :On configure certains nœuds du backbone pour quils génèrent deux types de trafics : • Un trafic voix dont le débit est équivalent au quart (1/4) de la capacité du lien dédié au trafic "Voix" entrant au backbone (Voir Tableau 4.1) ; • Un trafic donnée dont le débit est équivalent au tiers (1/3) de la capacité du lien dédié au trafic "Donnée" entrant au backbone (Voir Tableau 4.1) ; - 57 -
  • 67. Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom"Chaque trafic entrant (voix et donnée) est véhiculé à travers le backbone vers les différentsLER.2.2 Résultats et interprétations2.2.1 Estimation des charges des liens constituant le backbone On se propose destimer loccupation de chaque lien du backbone. Loccupation dunlien sera exprimée en pourcentage de la bande passante utilisée. En dautres termes : Débit envoyé sur ce lien Occupation d un lien = Bande Passante du lien Par exemple, si on envoie un débit de 155.52Mbps sur un lien STM-4 (ayant unebande passante de 622.08Mbps), on aura une occupation de lien de 25%. Le tableau 4.2 résume lensemble des mesures effectuées sur loccupation des liens. Lesmesures ont été faites : – Une première fois avec le backbone fonctionnant en mode IP classique ; – Une deuxième fois avec le backbone fonctionnant en mode MPLS TE. Occupation du lien (%) Lien Type du lien Mode Mode IP classique MPLS TE Bardo Belvédère 2 STM-4 56 62 Bardo Kasbah 2 STM-4 54 77 Ariana Belvédère 2 STM-4 58 63 Ariana Kasbah 1 STM-4 55 68 Menzeh Hached 2 STM-4 45 66 Menzeh Belvédère 2 STM-4 46 68 Marsa Hached 2 STM-4 38 70 Marsa Ouardia 1 STM-4 35 69 Ben Arous Hached 2 STM-4 88 90 Ben Arous Ouardia 2 STM-4 85 96 Nabeul Ouardia 2 STM-4 59 76 Nabeul Sousse 2 STM-4 62 90 Bizerte Ouardia 2 STM-4 54 76 Bizerte Béja 1 STM-4 50 53 Moknine Sousse 2 STM-4 36 80 Moknine Sfax 1 STM-4 32 75 - 58 -
  • 68. Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom" Gafsa Sfax 2 STM-4 35 70 Gafsa Gabés 2 STM-4 48 83 Hached Ouardia 1 STM-4 100 81 Ouardia Kasbah 1 STM-4 100 79 Kasbah Belvédère 1 STM-4 100 85 Belvédère Hached 1 STM-4 100 74 Hached Kasbah 1 STM-16 95 88 Hached Sfax 1 STM-16 98 86 Hached Gabés 1 STM-16 100 84 Belvédère Ouardia 1 STM-16 100 90 Belvédère Sousse 1 STM-16 100 91 Kasbah Sfax 1 STM-16 96 97 Kasbah Kairouan 1 STM-16 100 92 Ouardia Sousse 1 STM-16 100 89 Ouardia Béja 1 STM-16 100 93 Sfax Gabés 1 STM-16 87 76 Sfax Kairouan 1 STM-16 83 88 Sfax Sousse 2 STM-4 /1 STM-16 100 92 Kairouan Sousse 2 STM-4 100 83 Béja Kairouan 1 STM-4 / 1 STM16 77 70 Tableau 4.2 : Loccupation des liens Ce tableau, présenté ainsi, nest pas très parlant. Pour cela, on a rapporté ces mesuresdirectement sur le schéma du backbone, en utilisant un code couleur approprié (Voire Figure4.5 et Figure 4.6).Figure 4.5 : Occupation des liens (mode IP classique) Figure 4.6 : Occupation des liens (mode MPLS TE) 30% - 65% 65% - 99% 99% - 100% - 59 -
  • 69. Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom" La figure 4.6 traduit un certain équilibrage des charges sur tout le backbone et du coupune utilisation plus optimale des ressources du réseau (presque tous les liens sont orange).Cette performance a été rendue possible grâce à lutilisation du Traffic Engineering. La figure 4.5 montre lexistence de plusieurs liens saturés, alors que dautres liens sontsous-utilisés. Ceci sexplique par le fait que le routage IP classique ne prend pas enconsidération les capacités disponibles des liens, puisque son seul critère est la recherche duplus court chemin. Donc, pour router les paquets, il a tendance à sur-utiliser les nœudsLER/LSR et donc à saturer les liens STM-16 bien quil aurait pu utiliser des routes -évidement plus longues et de plus fiables capacités - mais ayant de la bande passante nonutilisée. Voyant ceci sur un cas de figure : Supposant quon a un trafic à envoyer depuis le LER Moknine vers le LER Ariana. Lechemin le plus court sera de passer par Sousse et Belvédère à travers un lien STM-16 (VoirFigure 4.7). Ce lien à grande chance dêtre saturé. Ce qui se traduira pour le trafic de Mokninepar des pertes et des délais très importants. Moknine Sousse Belvédère Ariana Figure 4.7 : Exemple de route IP Dun autre côté, des liens rattachant des nœuds comme Nabeul et Ben Arous peuventêtre partiellement disponibles et donc peuvent véhiculer le trafic de Moknine jusquà Ariana(Voir Figure 4.8). - 60 -
  • 70. Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom" Ben Arous Nabeul Moknine Sousse Hached Ouardia Belvédère Ariana Figure 4.8 : Exemple de route MPLS TE IP classique est incapable de prendre une décision de re-routage de trafic à travers uneroute plus longue même si elle est plus disponible. Tout ce quil peut faire, cest mettre lespaquets sur file dattente pour le lien STM-16. Avec MPLS TE, le choix des routes est étroitement lié à la disponibilité des liens.Donc entre le chemin le plus court et le chemin le plus disponible le choix pour MPLS TE estévident.2.2.2 Estimation du délai On va essayer dapprécier limpacte que peut avoir lutilisation de MPLS TE sur leparamètre délai. Pour cela, on va mesurer "le délai normalisé par le nombre de saut". Cest-à-dire que pour chaque paquet reçu, on mesure son délai de bout en bout puis en divise par lenombre de saut quil a effectué depuis la source jusquà la destination. En dautres termes : Délai de bout en bout Délai normalisé par le nombre de saut = Nombre de Saut Ce paramètre reflète en réalité le temps de séjour moyen dun paquet dans une filedattente (puisque le délai de propagation et les autres composantes du délai sontnégligeables).La figure 4.9 représente les courbes relatives aux délais. Les mesures ont été faites : – Une première fois avec le backbone fonctionnant en mode IP classique : Dans ce cas les trafics Voix et Donnée sont traités de la même manière, puisquil ny a pas un - 61 -
  • 71. Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom" mécanisme de classification. Cest pour ça quon a représenté une seule courbe de délai pour les deux trafics (courbe bleu). – Une deuxième fois avec le backbone fonctionnant en mode MPLS TE : Dans ce cas, on a un traitement différent du trafic Voix et du trafic Donnée. Donc on a représenté deux courbes de délai relatives chacune à un type de trafic (courbe rouge et verte). Trafic - mode IP Trafic Donnée - mode MPLS TE Trafic Voix - mode MPLS TE Figure 4.9 : Délai normalis é par le nombre de saut On remarque que pour le mode IP, on a un d qui varie autour de 70ms. Lorsquon élaipasse au mode MPLS TE, on observe une différence nette entre le délai moyen du traficDonnée et le délai moyen du trafic Voix. Le trafic Voix observe une chute de délaiconsidérable pour atteindre une moyenne de 35ms. Cette valeur est assez satisfaisante pour letransfert de la voix. Puisque en regardant le backbone, on saperçoit que les deux destinationsles plus éloignées sont distantes de 4 sauts. Donc si le processus MPLS TE privilégie le traficVoix et lui assigne assez souvent le plus court chemin, ce trafic aura un délai de bout en boutne dépassant pas les 140ms (35*4). Ce qui est acceptable en téléphonie vu quon tolère jusquà150ms de délai. Quant au trafic Donnée, sont délai augmente jusquà une moyenne de 105ms. Ce quinest pas très handicapant pour les services Donnée Dun autre côté, il est intéressant de remarquer quen passant vers le mode MPLS TE,la marge de fluctuation des courbes de délai a diminué considérablement surtout pour le traficVoix. Ceci traduit léquilibrage des charges dans les files dattente - 62 -
  • 72. Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom"2.2.3 Estimation du taux de perte Pour lestimation des pertes, on a suivi la même approche que pour le délai. Et on a putracer trois courbes relatives : • au trafic en utilisant le routage IP classique ; • au trafic Voix en utilisant MPLS TE ; • au trafic Donnée en utilisant MPLS TE. Trafic - mode IP Trafic Donnée - mode MPLS TE Trafic Voix - mode MPLS TE Figure 4.10 : Le taux de perte Le taux de perte est assez élevé en utilisant un routage classique (15%). Ces pertessont dues à la saturation de certains liens du backbone (Voir Figure 4.5). Un tel taux de pertene permet pas de véhiculer correctement le trafic Voix, puisquen téléphonie le seuilmaximum permis est de 2%. Le taux de perte est presque nul lorsque le réseau utilise le mode MPLS TE. Ceci estconforme au résultat obtenu pour lestimation des charges des liens, puisque ces derniers sonttous non saturés (Voir Figure 4.6).Conclusion Les simulations que nous avons réalisées sur le backbone de Tunisie Télécom ontpermis de mettre en évidence plusieurs constats : dabord, il est évident que le routage IPclassique nest pas du tous approprié pour véhiculer du multiservice. Ensuite, MPLS TE estune approche qui sest montrée très performante quant à loptimisation de lutilisation desressources du réseau, dautant plus quelle permet la transmission de trafic multiservice enrespectant les exigences des différentes applications. - 63 -
  • 73. Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom" Enfin, il est intéressant de remarquer quun taux de perte de 0% dépasse de loin lesparamètres dont on a besoin. Donc on pourra penser par exemple à diminuer le nombre deliens dans le backbone au risque daugmenter le taux de perte, sans dépasser les seuils desexigences respectives des applications. Et ainsi réaliser des gains économiques. - 64 -
  • 74. Conclusion générale Conclusion générale Lobjectif de ce projet de fin détude est lanalyse des performances de MPLS en termede "Traffic Engineering". Nous avons abordé cette thématique en commençant par une étude théorique de latechnologie MPLS. Pour cela, nous avons étudié dans le Chapitre I le principe defonctionnement de MPLS, nous avons fait le tour des concepts relatifs à ce dernier et présentéles applications quil permet de réaliser. Dans le chapitre II, nous nous sommes penchés surlune des plus importantes applications de MPLS à savoir la prise en charge du "TrafficEngineering" et nous nous sommes concentrés dans cette partie sur létude du protocole dedistribution de label RSVP TE. Ceci nous a préparé à la deuxième phase de ce projet qui est la simulation dufonctionnement de MPLS. Nous avons pour cela préparer lenvironnement de simulation NS2pour quil soit capable de prendre en charge les mécanismes et protocoles relatives à MPLS(en particulier RSVP TE). Ainsi, nous avons dans le chapitre III, réussi à implémenter un réseau MPLS et àsimuler quelques unes de ses fonctionnalités telles que la création de LSP, la réservation deressources ou le re-routage en cas de pannes. Nous avons aussi réalisé un ensemble demesures qui ont permis daboutir aux conclusions suivantes : Dabord, contrairement à lIP classique, MPLS TE privilégie le choix des chemins àdisponibilité suffisante plutôt que les chemins les plus courts. Les courbes de Bande passante,perte, délai et gigues que nous avons dressées ont montré le bien fondé de cette approche. Ensuite, MPLS TE permet de garantir une qualité de service minimale à uneapplication donnée grâce au mécanisme de réservation de ressource quopère RSVP TE sur lesLSP quil construit. Puis, nous avons mis en évidence la robustesse de MPLS TE face aux pannes quipeuvent survenir dans le réseau grâce à sa fonction de re-routage. Enfin, On peut affirmer que MPLS TE permet datteindre un haut niveaudoptimisation de réseau et de satisfaire ainsi plus efficacement les demandes des applicationsrendant possible de véhiculer plusieurs types de trafic sur un réseau IP. Dans le chapitre IV, nous avons essayé dévaluer lapport quaura lintégration delapproche TE dans le backbone de Tunisie Télécom. Nous avons montré que le routage - 65 -
  • 75. Conclusion généraleclassique ne permet pas de véhiculer voix et donnée sur le même réseau. Alors quen utilisantle TE on a pu réaliser un certain équilibrage de charges sur les liens du backbone et ainsiaméliorer nettement les paramètres de perte et de délai. Le "Traffic Engineering" réalise unerépartition plus fine des ressources dans le réseau de lopérateur permettant dun côté d’éviterle recours à une politique de surdimensionnement des réseaux physiques et dun autre côtéd’associer voix/donné sur le même backbone On propose comme travail complémentaire de réaliser une application doptimisationdu réseau basée sur des algorithmes méta-heuristiques. On imposera comme contraintes : • Les seuils de QoS (délai, perte, gigue, etc.) permis pour chaque type de trafic ; • Les capacités des liens ; • Les statistiques relatives au trafic national. On aura comme résultat un câblage optimal du backbone MPLS avec un maximumdéconomie sur les liens. Plusieurs autres domaines et axes de recherche intéressants liés à cette technologierestent à explorer. Nous en citons quelques uns : • La comparaison des approches CR-LDP et RSVP TE ; • La comparaison des performances de MPLS par rapport à ATM ; • Létude de lassociation Diffserv - MPLS ; • Lamélioration des mécanismes de files dattente utilisés ; • MPLS VPN ; • GMPLS, qui est une généralisation de MPLS pour supporter les réseaux optiques. - 66 -
  • 76. Références Références[1] Jean-Louis Mélin, Qualité de service sur IP, Eyrolles, 2001[2] Jean-Antoine Montagnon, T Huong Tran, MPLS et les réseaux d’entreprise, ON-X/Consulting, 2002[3] Eric Osborne, Ajay Simha, Traffic Engineering with MPLS, Cisco Press, 2002[4] Paul Brittain, Adrian Farrel, MPLS Traffic Engineering : a choice of signaling protocols,Data Connection Limited, 2000[5] Guillaume aka guill, Nadim aka rusher, guill.net ©1999-2005, http://www.guill.net/[6] Cisco IP QoS Introduction, Copyright ? 001, Cisco Systems, Inc. 2[7] nsnam web pages, http://www.isi.edu/nsnam/[8] Kevin Fall, Kannan Varadhan, The ns Manual, The VINT Project, 14 Avril 2002[9] Marc Greis Tutorial for the Network Simulator ns,http://www.isi.edu/nsnam/ns/tutorial/index.html[10] Gaeil Ahns homepage, http://flower.ce.cnu.ac.kr/~fog1/mns/[11] Alexander Sayenko homepage, http://www.cc.jyu.fi/~sayenko/[12] RSVPns homepage, http://titan.cs.uni-bonn.de/~greis/rsvpns/index.html[13] RSVP-TEns homepage, http://netgroup-serv.iet.unipi.it/rsvp-te_ns/ - 67 -
  • 77. RésuméLe principe de "Best Effort" ne peut offrir aucune garantie de QoS pour lesexigences des nouvelles applications (vidéo, voix, etc). En même temps, il neserait pas raisonnable dabandonner les réseaux IP qui sont tellement répandusde nos jours. MPLS apporte une solution ingénieuse à ce problème et rendainsi possible le multiservice sur les réseaux IP. Cette technologie a réussi àconjuguer la simplicité de IP avec la gestion de QoS dATM.MPLS a permis entre autres de réaliser des applications comme le "TrafficEngineering" qui permet daccéder à un haut niveau doptimisation des réseaux,facilitant ainsi le passage au "tout IP".Mot clés MPLS, Traffic Engineering, commutation de label, RSVP TE.

×