Vous êtes sur la page 1sur 77

RAPPORT DE PROJET DE FIN DETUDES

Filire

Ingnieurs en Tlcommunications

Option

Ingnierie des rseaux

Analyse des performances de MPLS en terme de "Traffic Engineering" dans un rseau multiservice
Elabor par :

Oussama FOUDHAILI

Encadr par :

M. Rached HAMZA M. Jamel SAKKA

Anne universitaire : 2004/2005

"L o tout finira, l o tout commencera!" Confucius

Remerciements
Je tiens tout dabord remercier Monsieur Rached Hamza (Sup'Com) pour m'avoir fait l'honneur d'tre mon encadreur. J'adresse galement mes trs vifs remerciements Monsieur Jamel Sakka (Tunisie Tlcom) pour sa comptence, sa patience et son esprit ouvert et dynamique.

Je tiens naturellement remercier aussi le cadre enseignant et le corps administratif de Sup'Com pour m'avoir donner l'accs une formation qui m'a permis de m'amliorer scientifiquement et humainement.

Une pense amicale est adresse mes amis Kamel Zidane et Anis Souissi avec qui j'ai partag le mme foyer pendant trois ans et dont la prsence m'a permis de mieux vivre aussi bien les temps de stress que les temps de bonheur.

Finalement, que tous ceux qui ne sont pas nomms ici, mais qui ont contribu de prs ou de loin au bon droulement de ce projet, trouvent l'assurance de ma pleine gratitude.

Oussama Foudhaili

Table des Matires


Introduction Gnrale 1

Capitre I : MultiProtocol Label Switching (MPLS)

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 Contrle 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 Cration 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 rseaux privs 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................................................................................................................15 Chapitre 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-

Capitre III : Implmentation et simulation des fonctionnalits 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 Dlai de bout en bout (End to End Delay) ......................................................32 1.4 Gigue (Jitter) ...................................................................................................33 1.5 Les exigences des diffrentes applications IP en terme de QoS .....................34 2 L'environneme nt de simulation..............................................................................35 2.1 L'intrt dutiliser un simulateur .....................................................................35 2.2 Prsentation de NS2 ........................................................................................35 2.3 Fonctionnement de NS2 ..................................................................................36 2.4 Les modifications apporter NS2 ................................................................38 2.5 Avantages, limites et difficults de NS2 .........................................................39 3 Simulation des fonctionnalits de MPLS TE.........................................................40 3.1 Le scnario de simulation................................................................................40 3.2 Rsultats de la simulation et interprtations ....................................................42 3.2.1 "Bande passante" et "Taux de perte en paquets" ......................................43 3.2.2 "Dlai de bout en bout " et "Gigue"...........................................................48 Conclusion................................................................................................................52 Chapitre IV : Evaluation des performances de MPLS TE sur le backbone de "Tunisie Tlcom" 53 Introduction...............................................................................................................53 1 Description du backbone MPLS de Tunisie Tlcom...........................................53 1.1 Dfinition de Backbone ...................................................................................53 1.2 Structure du backbone de Tunisie Tlcom....................................................54 2 Simulation et rsultats............................................................................................57 2.1 Scnario de la simulation ................................................................................57 2.2 Rsultats et interprtations ..............................................................................58 2.2.1 Estimation des charges des liens constituant le backbone ........................58 2.2.2 Estimation du dlai ...................................................................................61 2.2.3 Estimation du taux de perte.......................................................................63 Conclusion................................................................................................................63 Conclusion gnrale 65

Rfrences

67

- ii -

Table des figures


Figure 1.1 : Exemple d'un rseau MPLS .......................................................................3 Figure 1.2 : l'encapsulation MPLS dans diffrentes technologies .................................6 Figure 1.3 : Format du shim MPLS ...............................................................................6 Figure 1.4 : Pile de labels...............................................................................................7 Figure 1.5 : Unsolicited downsteam ..............................................................................8 Figure 1.6 : Downsteam-on-demand ..............................................................................9 Figure 1.7 : MPLS VPN...............................................................................................14 Figure 2.1 : Le routage classique .................................................................................16 Figure 2.2 : Le Traffic Engineering selon MPLS ........................................................18 Figure 2.3 : L'encapsulation des messages RSVP TE..................................................21 Figure 2.4 : Format des messages RSVP TE ...............................................................22 Figure 2.5 : Format des objets RSVP TE.....................................................................22 Figure 2.6 : Format du Path message ...........................................................................23 Figure 2.7 : Format du Resv message ..........................................................................23 Figure 2.8 : Path et Resv messages, lors de l' tablissement de chemin .......................26 Figure 2.9 : Etablissement d'un CR-LDP LSP.............................................................29 Figure 3.1 : Illustration du concept de bande passante ................................................31 Figure 3.2 : Illustration du concept de dlai de bout en bout.......................................32 Figure 3.3 : Illustration du concept de la gigue ...........................................................34 Figure 3.4 : Les tapes dune simulation sur NS2 .......................................................37 Figure 3.5 : La topologie de simulation visualise par NAM ......................................41 Figure 3.6 : Bande Passante .........................................................................................43 Figure 3.7 : Taux de paquets perdus ............................................................................43 Figure 3.8 : Situation du trafic entre les instants 0.2s et 6s .........................................44 Figure 3.9 : Situation du trafic entre les instants 6s et 7s ............................................44 Figure 3.10 : Situation du trafic entre les instants 7s et 9s ..........................................45 Figure 3.11 : Situation du trafic entre les instants 9s et 11s ........................................46 Figure 3.12 : Situation du trafic entre les instants 11s et 13s ......................................46 Figure 3.13 : Situation du trafic entre les instants 13s et 15s ......................................47 Figure 3.14 : Dlai de bout en bout ..............................................................................48 Figure 3.15 : Gigue relatif au trafic TR .......................................................................48

- iii -

Figure 3.16 : Gigue relatif au trafic HP .......................................................................49 Figure 3.17 : Gigue relatif au trafic BE .......................................................................49 Figure 3.18 : Zoom relatif la courbe de gigue...........................................................50 Figure 3.19 : Zoom relatif la courbe de dlai entre les instant 8.5s et 8.85s.............51 Figure 4.1 : La structure du backbone de Tunisie Tlcom.........................................54 Figure 4.2 : La disposition gographique du backbone de Tunisie Tlcom ..............55 Figure 4.3 : Backbone de Tunisie Tlcom .................................................................55 Figure 4.4 : le backbone tel que gnr par NS2 .........................................................57 Figure 4.5 : Occupation des liens (mode IP classique ) ................................................59 Figure 4.6 : Occupation des liens (mode MPLS TE) ...................................................59 Figure 4.7 : Exemple de route IP .................................................................................60 Figure 4.8 : Exemple de route MPLS TE ....................................................................61 Figure 4.9 : Dlai normalis par le nombre de saut .....................................................62 Figure 4.10 : Le taux de perte ......................................................................................63

Liste des tableaux


Tableau 1.1 : Modes de fonctionnement de quelques protocoles de distribution de label........................................................................................................12 Tableau 2.1 : Les messages RSVP TE.........................................................................21 Tableau 3.1 : Les exigences des diffrentes applications IP en terme de QoS ............34 Tableau 3.2 : Les flux considrs dans la simulation ..................................................41 Tableau 3.3 : Timing de la simulation .........................................................................42 Tableau 4.1 : Descriptif des liens raccords au backbone ...........................................56 Tableau 4.2 : L'occupation des liens ............................................................................59

- iv -

Acronymes
ACK ATM AToM AWK BE BGP CBR CPU CR-LDP CR-LSP CSPF EoIP ER-LSP FEC FR FTP GCC GMPLS HP HTTP ICMP IETF IGP IP IS-IS ISP LAN LDP LER LSP LSR MAC MNS MPLS NGN NS2 OSPF OTCL acknowledgment Asynchronous Transfer Mode Any Transport over MPLS Aho, Weinberger et Kernighahn Best effort (acronyme propre ce rapport) Border Gateway Protocol Constant Bit Rate Central Processing Unit Constraint-based Routing over Label Distribution Protocol Constraint-based Routing-LSP Constrained Shortest Path First Everything over IP Explicit Routing -LSP Forwarding Equivalence Class Frame Relay File Transfer Protocol GNU C/C++ Generalized MPLS Haute Priorit (acronyme propre ce rapport) HyperText Transfer Protocol Internet Control Message Protocol Internet Engineering Task Force Interior Gateway Protocol Internet Protocol Intermediate System-to-Intermediate System Internet Service Provider Local Area Network Label Distribution Protocol Label Edge Router Label Switched Path Label Switch Router Media Access Control MPLS Network Simulator MultiProtocol Label Switching Next Generation Networks Network Simulator 2 Open Shortest Path First Object-oriented Tcl

-v -

PHOP PIM PPP QoS RIP RSVP TE SDH SONET SPF STM-x TCL TCP TDP TE TR TTL UDP VCI VoIP VPI VPN WAN WFQ

Previous Hop Protocol Independent Multicast Point-to-Point Protocol Quality of Service Routing Information Protocol Resource ReSerVation Protocol - Traffic Engineering Synchronous Digital Hierarchy Synchronous Optical NETwork Shortest Path First Synchronous Transport Module level x Tool Command Langage Transport Control Protocol Tag Distribution Protocol Traffic Engineering Temps Rel (acronyme propre ce rapport) Timt to live User Datagram Protocol Virtual Channel Identifier Voice over IP Virtual Path Identifier Virtual Private Network Wide Area Network Weighted Fair Queuing

- vi -

Introduction gnrale

Introduction Gnrale
La toile Internet connat actuellement un dveloppement vertigineux. Ce qui a fait de IP un protocole presque universel. Le succs de ce dernier repose sur sa grande simplicit puisqu'il se base sur le modle Best Effort. Toutefois, ce mme point qui a fait sa force, constitue actuellement sa faiblesse. Car le modle Best Effort a montr ses limites face aux nouveaux besoins des applications, puisque la demande s'est diversifie (data, voix, vido, etc.) et les services sont de plus en plus gourmands en ressources. Les nouvelles applications exigent aujourd'hui de complexifier les rseaux et de prendre en compte les spcifications propres chacune d'elles pour qu'elles puissent fonctionner correctement. En, d'autres termes, il est primordial d'instaurer la notion de la Qualit de Service (QoS) dans les rseaux tlcom.

La rponse la question de QoS a t pour longtemps ATM. Car l'aspect non connect de IP rend difficile d'envisager de lui intgrer des services temps rel.

D'un autre ct, les rseaux IP ont pris une ampleur tellement grande qu'on ne peut plus envisager de crer une architecture nouvelle rpondant aux besoins de QoS. Et mme l'association IP/ATM a montr ses limites. La solution est alors de dfinir des mcanismes complmentaires au fonctionnement de IP de base, permettant de prendre en compte les exigences propres de chaque type de service. Ceci quitte introduire une complexit supplmentaire au fonctionnement de IP.

C'est l que MPLS s'est impos comme une solution leader. MPLS a russi conjuguer la simplicit de IP avec l'efficacit d'ATM dans la gestion du multiservice.

MPLS fait galement partie dun mouvement densemble vers les NGN (Next Generation Networks) dont le but est de raliser la convergence voix/donnes dans une perspective gnrale de "tout IP" (EoIP : Everything over IP).

MPLS constitue aussi une alternative la commutation de circuit, encore largement utilise en tlphonie. Ce type de commutation prsente l'inconvnient de gnrer un gaspillage vident de ressources, puisque c'est une technique ressources ddies. MPLS remdie ce problme en mettant en uvre des mcanismes permettant de faire passer du trafic haute exigence, tel que la voix, dans un rseau ressources partages, sans pour autant -1-

Introduction gnrale dgrader sa qualit. On peut ainsi passer outre la technique de commutation de circuit et utiliser la commutation de paquet/label. Le rseau sera alors utilis d'une faon plus optimale, ce qui constitue un gain conomique pour les oprateurs et les fournisseurs de services.

De plus, avoir grer un seul rseau est trs important pour un oprateur vu que a lui permet de rduire ses cots. D'autant plus que migrer vers les rseaux MPLS n'est pas trs coteux puisqu'il existe des solutions qui n'exigent pas de changer tous les quipements : on peut juste patcher les routeurs dj installs.

Dans ce rapport, on va s'intresser l'tude de MPLS et en particulier l'application "Traffic Engineering (TE)". Les chapitres I et II seront consacrs une vue thorique de ces deux concepts. Ensuite, on dcrira, dans le chapitre III, l'implmentation et les simulations qui ont permis d'analyser les performances de MPLS TE sur les rseaux multiservice. Pour enfin essayer d'valuer l'apport du Trafic Engineering sur le backbone national de Tunisie Tlcom.

-2-

Chapitre I : MultiProtocol Label Switching

Chapitre I : MultiProtocol Label Switching (MPLS)


Introduction
Prcisons ds prsent que MPLS est davantage une architecture qu'un protocole ou un modle de gestion. Ainsi, l'architecture MPLS est compose d'un certain nombre de protocoles et de mcanismes dfinis, ou en cours de dfinition. Nous allons, le long de ce premier chapitre, faire le tour de la technologie MPLS. Nous commencerons par expliquer son principe de fonctionnement. Nous dtaillerons ensuite les concepts relatifs aux labels et leurs distributions. Nous finirons par donner un aperu des applications que MPLS permet de raliser.

1 Principe de fonctionnement de MPLS


Ingress LER LER

12.3.2.125 Site 1

L=18 LSR LSR LSR L=21 L=3 LER L=42 Egress LER 12.3.2.125 Site 2

Domaine MPLS
L=10921

LSR

LSR

LSR

Figure 1.1 : Exemple d'un rseau MPLS

Un rseau MPLS est constitu de deux types d'quipements : LSR (Label Switch Router) : c'est un quipement de type routeur, ou commutateur qui appartient un domaine MPLS.

-3-

Chapitre I : MultiProtocol Label Switching LER (Label Edge Router) : c'est un LSR qui fait l'interface entre un domaine MPLS et le monde extrieur. En gnral, une partie de ses interfaces supportent le protocole MPLS et l'autre un protocole de type IP. Il existe deux types de LER : Ingress LER : c'est un routeur qui gre le trafic qui entre dans un rseau MPLS. Egress LER : c'est un routeur qui gre le trafic qui sort d'un rseau MPLS.

Avant d'examiner le fonctionnement d'un rseau MPLS, on va passer en revu le principe d'acheminement des paquets dans un rseau IP classique et ainsi pouvoir faire une comparaison des deux techniques. Dans un rseau IP classique, il y a mise en oeuvre d'un protocole de routage (RIP, OSPF, IS-IS, etc.) Ce protocole sera excut indpendamment par chaque nud. A la convergence du protocole de routage, chaque nud aura une vision plus ou moins complte du rseau et pourra du coup calculer une table de routage contenant l'ensemble des destinations. Chaque destination sera associe un "prochain saut" ou "Next Hop".

Voyant maintenant le cas d'un rseau MPLS : La mise en uvre de MPLS repose sur la dtermination de caractristiques communes un ensemble de paquets et dont dpendra l'acheminement de ces derniers. Cette notion de caractristiques communes est appele Forwarding Equivalence Class (FEC). Une FEC est la reprsentation dun ensemble de paquets qui partagent les mmes caractristiques pour leur transport. Le routage IP classique distingue les paquets en se basant seulement sur les adresses des rseaux de destination (prfixe dadresse). MPLS constitue les FEC selon de nombreux critres : adresse destination, adresse source, application, QoS, etc.

Quand un paquet IP arrive un ingress LER, il sera associ une FEC. Puis, exactement comme dans le cas d'un routage IP classique, un protocole de routage sera mis en uvre pour dcouvrir un chemin jusqu' l'egress LER (Voir Figure 1.1, les flches rouges). Mais la diffrence d'un routage IP classique cette opration ne se ralise qu'une seule fois. Ensuite, tous les paquets appartenant la mme FEC seront achemins suivant ce chemin qu'on appellera Label Switched Path (LSP). Ainsi on a eu la sparation entre fonction de routage et fonction de commutation : Le routage se fait uniquement la premire tape. Ensuite tous les

-4-

Chapitre I : MultiProtocol Label Switching paquets appartenant la mme FEC subiront une commutation simple travers ce chemin dcouvert. Pour que les LSR puissent commuter correctement les paquets, le Ingress LER affecte une tiquette (appele aussi Label) ces paquets (label imposition ou label pushing). Ainsi, si on prend l'exemple de la figure 1.1, Le LSR1 saura en consultant sa table de commutation que tout paquet entrant ayant le label L =18 appartient la FEC tel et donc doit tre commut sur une sortie tel en lui attribuant un nouveau label L=21 (label swapping). Cette opration de commutation sera excuter par tous les LSR du LSP jusqu' aboutir l'Egress LER qui supprimera le label (label popping ou label disposition) et routera le paquet de nouveau dans le monde IP de faon traditionnelle. L'acheminement des paquets dans le domaine MPLS ne se fait donc pas base d'adresse IP mais de label (commutation de label).

Il est claire qu'aprs la dcouverte de chemin (par le protocole de routage), il faut mettre en uvre un protocole qui permet de distribuer les labels entre les LSR pour que ces derniers puissent constituer leurs tables de commutation et ainsi excuter la commutation de label adquate chaque paquet entrant. Cette tche est effectue par "un protocole de distribution de label" tel que LDP ou RSVP TE. Les protocoles de distribution de label seront repris plus loin dans un paragraphe part.

Les trois oprations fondamentales sur les labels (Pushing, swapping et popping) sont tout ce qui est ncessaire pour MPLS. Le Label pushing/popping peuvent tre le rsultat d'une classification en FEC aussi complexe qu'on veut. Ainsi on aura plac toute la complexit aux extrmits du rseau MPLS alors que le cur du rseau excutera seulement la fonction simple de label swapping en consultant la table de commutation.

2 Les labels
Un label a une signification d'identificateur local d'une FEC entre 2 LSR adjacents et mappe le flux de trafic entre le LSR amont et le LSR aval. La figure 1.2, illustre la mise en uvre des labels dans diffrentes technologies. Ainsi, MPLS fonctionne indpendamment des protocoles de niveau 2 (ATM, FR, etc.) et des protocoles de niveau 3 (IP, etc.). C'est ce qui lui vaut son nom de "MultiProtocol Label Switching".

-5-

Chapitre I : MultiProtocol Label Switching

PPP (Packet over SONET/SDH) Ethernet Frame Relay ATM

En-tte PPP

Shim MPLS

En-tte couche 3

En-tte Ethernet En-tte FR GFC VPI

Shim MPLS Shim MPLS VCI PTI CLP

En-tte couche 3 En-tte couche 3 HEC DATA

Label
Figure 1.2 : l'encapsulation MPLS dans diffrentes 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 insre un en-tte (32 bits) entre la couche 2 et la couche 3 appel shim MPLS. La figure 1.3 illustre le format d'un 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

TTL

Figure 1.3 : Format du shim MPLS

LABEL (20 bits) : Contient le label.

EXP (3 bits) : Initialement rserv pour une utilisation exprimentale. Actuellement, la plus part des implmentations utilise ce champ comme indicateur de QoS. Gnralement, c'est une copie du champ PRECEDENCE (PPP) dans l'en-tte IP. En IP, la prcdence dfinit la priorit d'un paquet (0 : priorit suprieure, 7 : priorit infrieure).

S (1 bit) : Indique s'il y a empilement de labels (il est en fait commun d'avoir plus qu'un label attach un paquet). Cette notion sera reprise dans le paragraphe suivant. Le bit S est 1 lorsque le label se trouve au sommet de la pile, 0 sinon.

TTL (8 bits) : Mme signification que pour IP. Ce champ donne la limite suprieure au nombre de routeurs qu'un paquet peut traverser. Il limite la dure de vie du paquet. Il est initialis une certaine valeur, puis dcrment de un par chaque routeur qui traite le paquet.

-6-

Chapitre I : MultiProtocol Label Switching Lorsque ce champ atteint 0, le paquet est rejet. L'utilisation de ce champ vite les boucles de routage.

3 Pile de labels (Label Stack)


Comme on l'a dj voqu, il est commun d'avoir plus qu'un label attach un paquet. Ce concept s'appelle empilement de label. L'empilement de label permet en particulier d'associer plusieurs contrats de service un flux au cours de sa traverse du rseau MPLS. Dans le cas de deux niveaux de label, on pourra relier deux rseaux d'un rseau priv au travers d'un rseau oprateur (Voir figure 1.4), en utilisant un niveau de labels au niveau oprateur, et un niveau de labels au niveau du rseau priv. Les LSR de frontire de rseau auront donc la responsabilit de pousser (ou tirer) la pile de labels pour dsigner le niveau d'utilisation courant de label.

10.2.0.174

10.2.0.174

Site 1
3 9 2

Site 2
1

Domaine MPLS Oprateur

2 6 2

Figure 1.4 : Pile de labels

-7-

Chapitre I : MultiProtocol Label Switching L'utilisation de plusieurs niveaux de labels permet, lors d'interconnexions de disposer de plusieurs niveaux d'oprateurs. Chacun manipule les labels correspondant son niveau [1].

4 Concepts relatifs la distribution de labels


Pour comprendre comment les LSR gnrent et distribuent les labels, on doit aborder quelques concepts relatifs la distribution de labels [1].

4.1 Contrle de distribution des labels


Il existe deux modes de contrle de distribution des labels aux LSR voisins : Mode de contrle ordonn (Ordered control mode) : Dans ce mode, un LSR associe un label une FEC particulire, si : Il s'agit d'un Egress LER ; L'assignation (l'association Label, FEC) a t reue du LSR situ au saut suivant. Mode de contrle indpendant (Independent control mode) : Dans ce mode, les LSR sont libres de communiquer les associations entre label et FEC leurs voisins sans attendre de recevoir l'assignation du LSR situ au saut suivant. Ainsi, un LSR peut diffuser un label pour une FEC, quand bien mme il n'est pas prt communiquer sur ce label.

4.2 Distribution et gestion des labels


La distribution elle-mme des labels peut se faire suivant plusieurs mthodes : Descente systmatique (unsolicited downstream) : Le LSR en aval envoie le label au LSR prcdent (en amont) de manire systmatique (sans demande explicite). Ainsi dans l'exemple de la figure 1.5, LSR C demande au LSR B d'utiliser le Label 53 Pour la destination 182.65.10/24. LSR B, son tour, demande au LSR A d'utiliser le label 25 pour cette mme destination.
Utilisez le label 25 pour la destination 182.65.10/24 Utilisez le label 53 pour la destination 182.65.10/24 182.65.10/24

182.65.10/24

LSR A

LSR B Figure 1.5 : Unsolicited downsteam

LSR C

-8-

Chapitre I : MultiProtocol Label Switching Descente la demande (Downstream-on-Demand) : Dans ce mode, le LSR en aval envoie le label au LSR prcdent uniquement s'il a reu une requte. Et ceci mme s'il a dj gnr un label pour la FEC en question.
Utilisez le label 25 pour la destination 182.65.10/24 Utilisez le label 53 pour la destination 182.65.10/24 182.65.10/24

182.65.10/24

LSR A Demande de label pour la destination 182.65.10/24

LSR B Demande de label pour la destination 182.65.10/24

LSR C

Figure 1.6 : Downsteam-on-demand

4.3 Conservation des labels


Il existe deux modes que les LSR utilisent pour la conservation des labels reus : Mode de conservation libral (Liberal retention) : Dans ce mode, les LSR conservent les labels reus de tous leurs voisins. Il permet une convergence plus rapide face aux modifications topologiques du rseau et la commutation de trafic vers d'autres LSP en cas de changement. En contre partie, ce mode ncessite beaucoup de mmoire. Mode de conservation conservateur (Conservative retention) : Dans ce mode, les LSR retiennent uniquement les labels des voisins situs sur le saut suivant et ignorent tous les autres. Ce mode ncessite peu de mmoire. En contre partie, on aura une adaptation plus lente en cas d'erreur

4.4 Espace de labels (Label Space)


Les labels utiliss par un LSR pour l'assignation de labels un FEC sont dfinis de deux faons : 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 allous depuis un ensemble commun de labels : de la sorte, deux labels situs sur des interfaces distinctes possdent des valeurs distinctes.

-9-

Chapitre I : MultiProtocol Label Switching Par interface (per-interface label space) : Les domaines de valeurs des labels sont associs une interface. Plusieurs peuvent tre dfinis. Dans ce cas, les valeurs de labels fournies sur des interfaces diffrentes peuvent tre identiques. Il est clairement stipul qu'un LSR peut utiliser une assignation de label par interface, la condition express qu'il soit en mesure de distinguer l'interface depuis laquelle arrive le paquet. Il risque sinon de confondre deux paquets possdant le mme label, mais issus d'interfaces diffrentes.

4.5 Cration des labels


Plusieurs mthodes sont utilises pour la cration des labels, en fonction des objectifs recherchs. Fonde sur la topologie (Topology-based) : Cette mthode engendre la cration de labels lissue de lexcution normale des processus de routages (comme OSPF ou BGP). Fonde sur les requtes (Request-based) : Cette mthode de cration de labels est dclenche lors de lexcution dune requte de signalisation. Fonde sur le trafic (Traffic-based) : Cette mthode de cration de labels attend la rception dun paquet de donne pour dclancher lassignation et la distribution de labels. Le protocole IP-Switching de la socit Ipsilon illustre cette mthode.

La dernire mthode est un exemple de protocole fond sur le modle orient donnes (data-driven). Ce modle n'a pas t retenu par MPLS. Dans ce cas, l'assignation de labels n'est dclenche qu' la rception effective de paquets de donnes et non a priori comme en mode control-driven. Cette mthode prsente l'avantage de justifier le processus de cration de labels et de leur distribution qui se fait uniquement en prsence effective d'un trafic utilisateur. En revanche, elle a l'inconvnient d'obliger l'ensemble des routeurs du rseau fonctionner au dpart comme des routeurs traditionnels, avec l'obligation de disposer des fonctions de classification de paquets pour identifier les flux de trafic. En outre, il existe un dlai entre la reconnaissance d'un flux sur le rseau et la cration d'un label pour ce flux.

- 10 -

Chapitre I : MultiProtocol Label Switching Enfin, en prsence d'un nombre important de flux de trafic (sur un grand rseau), le processus de distribution de labels peut devenir complexe et lourd grer.

Les deux premires mthodes exposes sont des exemples d'assignation de labels tablis partir du modle orient contrle ( control-driven), savoir qu' l'inverse du modle prcdent, les labels sont assigns et distribus pralablement l'arrive des donnes de trafic de l'utilisateur. C'est le modle retenu et utilis par MPLS.

Voici les principaux protocoles de distribution de labels envisags :

TDP (Tag Distribution Protocol) : Prdcesseur de LDP. LDP (Label Distribution Protocol) : Protocole cr spcifiquement. BGP (Border Gateway Protocol) : Amlioration de BGP pour la distribution des labels PIM (Protocol Independent Multicast) : Amlioration de PIM pour la distribution des labels CR-LDP (Constraint-based Routing LDP) : Amlioration de LDP RSVP TE (Ressource ReSerVation Protocol Traffic Engineering) : Amlioration de RSVP

Les quatre premires approches sont fondes sur la topologie (Topology-based). Les deux dernires approches sont fondes sur les requtes (Request-based). Et ce sont ces deux protocoles de distribution de labels qui sont utiliss pour le MPLS Traffic Engineering. On va les revoir plus en dtail dans le chapitre II et on va consacrer notre tude pratique la simulation du protocole RSVP TE.

4.6

Modes de fonctionnement de quelques protocoles de distribution de label


Le tableau [3] ci-dessous prsente quelques protocoles de distribution de labels et

leurs modes de fonctionnements respectifs :

- 11 -

Chapitre I : MultiProtocol Label Switching

Protocole de distribution de label TDP et LDP TDP et LDP (avec ATM) RSVP TE Ordered Unordered/ Ordered Unordered Downstream unsolicited Ordered Downstream on Demand Downstream on Demand CR-LDP
Downstream unsolicited/ Downstream on Demand

Contrle

Distribution

Conservation

Espace de label

Cration

Liberal

Per platform

Topologybased

Conservative

Per interface

Topologybased

Conservative Liberal/ Conservative

Per platform Per platform/ Per interface

Requestbased Requestbased

Tableau 1.1 : Modes de fonctionnement de quelques protocoles de distribution de label

5 Les applications de MPLS


La motivation primaire de MPLS tait d'accrotre la vitesse de traitement des paquets au niveau des nuds intermdiaires. Cela dit, aujourd'hui MPLS offre peu sinon pas d'amlioration du tout dans ce sens : les routeurs actuels sont quips avec des circuits et des algorithmes permettant un acheminement (forwarding) des paquets extrmement rapide. Donc, traiter des paquets sur la base de label de 20 bits de MPLS n'est plus significativement rapide par rapport traiter des paquets sur la base d'adresse de 32 bits de IP. Aujourd'hui, les motivations relles pour dployer des solutions MPLS sont les applications que MPLS permet et qui taient trs difficiles voire impossibles mettre en uvre avec IP traditionnel. Ces applications sont trs importantes pour les oprateurs et les ISP (Internet Service Provider), tout simplement parce qu'elles peuvent tre vendues Il existe aujourd'hui quatre applications majeures de MPLS. Ces applications supposent la mise en uvre de composants adapts aux fonctionnalits recherches. L'implmentation de MPLS sera donc diffrente en fonction des objectifs recherchs. Cela se traduit principalement par une faon diffrente d'assigner et de distribuer les labels (Classification, protocoles de distribution de labels). Le principe d'acheminement des paquets fond sur l'exploitation des labels tant le mcanisme de base commun toutes les approches.

- 12 -

Chapitre I : MultiProtocol Label Switching

Les principales applications de MPLS concernent : Any Transport over MPLS (AToM) ; Le support des rseaux privs 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 l'indpendance 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 rseaux privs virtuels (MPLS VPN)


Un rseau priv virtuel (VPN) simule le fonctionnement d'un rseau tendu (WAN) priv sur un rseau public comme Internet. Afin d'offrir un service VPN fiable ses clients, un oprateur ou un ISP doit alors rsoudre deux problmatiques essentielles : Assurer la confidentialit des donnes transportes ; Prendre en charge des plans d'adressage priv, frquemment identiques.

La construction de VPN repose alors sur les fonctionnalits suivantes : Systmes de pare-feu (Firewall) pour protger chaque site client et permettre une interface scurise avec Internet ; Systme d'authentification pour vrifier que chaque site client change des

informations avec un site distant valide ; Systme de cryptage pour empcher l'examen ou la manipulation des donnes lors du transport sur Internet ; Tunneling pour permettre un service de transport multiprotocole et l'utilisation de plans d'adressage privs

MPLS permet de rsoudre efficacement la fonctionnalit de tunneling, dans la mesure o l'acheminement des paquets n'est pas ralis sur l'adresse de destination du paquet IP, mais sur la valeur du label assign au paquet [1]. Ainsi, un ISP peut mettre en place un VPN, en dployant un ensemble de LSP pour permettre la connectivit entre diffrents sites du VPN

- 13 -

Chapitre I : MultiProtocol Label Switching d'un client donn. Chaque site du VPN indique l'ISP l'ensemble des prfixes (adresses) joignables sur le site local. Le systme de routage de l'ISP communique alors cette information vers les autres sites distants du mme VPN, l'aide du protocole de distribution de labels. En effet, l'utilisation d'identifiant de VPN permet un mme systme de routage de supporter multiples VPN, avec un espace d'adressage ventuellement identique. Ainsi, chaque LER place le trafic en provenance d'un site dans un LSP fond sur une combinaison de l'adresse de destination du paquet et l'appartenance un VPN donn.
VPN 2

LER VPN 1 LER VPN 2 LER

VPN 2 VPN 1 LER LER

LER VPN 1

Figure 1.7 : MPLS VPN

Il existe une autre approche permettant de mettre en uvre des VPN sur les rseau IP : IPSec. IPSec privilgie la scurisation des flux d'information par encryptage des donnes, alors que MPLS se concentre plutt sur la gestion de la qualit de service et la priorit des flux. Le problme de scurit dans MPLS VPN est minimal dans le cas o le rseau est propritaire (non Internet). Cependant, si cette garantie n'est pas suffisante, il existe des solutions qui permettent d'utiliser en mme temps MPLS et IPSec [2] et ainsi construire des VPN disposant des avantages des deux approches en mme temps : la souplesse de MPLS et la scurisation de IPSec.

- 14 -

Chapitre I : MultiProtocol Label Switching

5.3 Le support de la qualit de service (MPLS QoS)


Le support de la QoS peut tre mise en uvre de deux faons sur MPLS [1] : Les trafics sur un mme LSP peuvent se voir affecter diffrentes files d'attente dans les routeurs LSR, selon la valeur du champ EXP de l'en-tte MPLS (Voir Figure 1.3). Le principe du champ EXP dans MPLS est le mme que le champ Precedence (PPP) dans IP (Voir plus haut le dtail de ce champ). L'utilisation du Traffic Engineering,

5.4 Le Traffic Engineering (MPLS TE)


Cette application est en troite relation avec la Qualit de Service, puisque sont rsultat immdiat est l'amlioration de paramtres tel que le dlai ou la gigue dans le rseau. Elle est tout de mme considre comme une application part entire par la plupart des industriels. Ceci vient du fait que MPLS TE n'est pas une simple technique de rservation de ressources pour les applications rseau. C'est un concept plus global qui se veut tre une solution qui vise augmenter les performances gnrales du rseau en jouant sur la rpartition quilibre des charges (trafics) dans le rseau pour ainsi avoir une utilisation plus optimale des liens. Le Traffic Engineering va tre repris d'une faon thorique dans le chapitre II, puis travers les simulations dans les chapitres III et IV.

Conclusion
Mme si le temps de routage nest plus lintrt de cette technologie, MPLS est toujours trs favorable pour s'imposer dans le monde des rseaux. Les offres MPLS au niveau de la qualit de service, de VPN ou de Traffic Engineering assureront ce protocole un succs tant au prs des utilisateurs que des oprateurs et fournisseurs de services. Son succs vient galement du fait quil ne remet pas en cause les protocoles existants de niveau 2 et 3. Dans le chapitre qui va suivre, on va s'approfondir dans la notion de Traffic Engineering et voir comment MPLS traite ce concept.

- 15 -

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 et les amliorations qu'il permet d'apporter l'utilisation du rseau. Ensuite, on va aborder les mcanismes et protocoles qui permettent de mettre en uvre des solutions MPLS TE dans un rseau.

1 Les motivations du Traffic Engineering

Le chemin le plus court

R1 R5
Cot : 15

R6
Cot : 15 Cot : 15 Cot : 15 Cot : 15

R2 R7
Cot : 15

R3
Cot : 15

R4

Figure 2.1 : Le routage classique

Dans 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 critre du plus court chemin [3]. Et puisque tous les liens ont le m me cot (15), les paquets venant de R1 ou R7 est qui sont destins R6 vont tous suivre le mme chemin (R2 R5 R6).

- 16 -

Chapitre II : MPLS Traffic Engineering Ceci peut conduire quelques problmes : supposant que tous les liens de la figure 2.1 supportent 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, soit R2 R5 R6. Si maintenant R7 veut envoyer 100Mbps R6. La m me procdure de routage fera que ce trafic utilisera aussi le chemin e plus court. En final, on aura deux trafics l de 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 d'attente et des pertes de paquets. Cet exemple est un cas explicite de sous utilisation des ressources du rseau vu que rellement, il existe un chemin dans le rseau qui n'est pas exploit et que son utilisation aurait permis de satisfaire les deux trafics.

Comment peut on alors rsoudre ce problme? Avec IP classique on pourra faire de sorte que les deux chemins aient le mme cot. Cependant cette solution marche seulement avec des rseaux de petite taille comme dans notre cas. Mais que ce passera-t-il si au lieu d'avoir sept routeurs, on ait eu 500? Les rseaux ATM permettent aussi de raliser une telle ingnierie des flux. Le problme c'est qu'ils introduisent en parallle une grande complexit de gestion : en effet IP et ATM sont deux techniques rseaux totalement diffrentes, avec parfois des contraintes non compatibles. Contrairement aux solutions IP et ATM, MPLS va permettre une simplification radicale de l'intgration de cette fonctionnalit dans les rseaux.

MPLS TE permet l'ingress LER de contrler le chemin que son trafic va emprunter pour atteindre une destination particulire. Ce concept est connu sous le nom de "Explicit Routing". Cette mthode est plus flexible que l'acheminement du trafic bas seulement sur l'adresse destination. MPLS TE rserve de la bande passante en construisant les LSP. Ainsi dans la topologie de la figure 2.2, LSR2 a la possibilit de construire deux LSP (Tunnel1 et Tunnel2) relatifs aux chemins : LSR2 LSR5 LSR6 LSR2 LSR3 LSR4 LSR6

- 17 -

Chapitre II : MPLS Traffic Engineering Les LSP ainsi construits sont appels MPLS TE LSP ou TE tunnels. On s'approfondira dans les mcanismes de cration des MPLS TE LSP dans le paragraphe 2.
Tunnel1

R1 LSR5
Cot : 15

LSR6
Cot : 15 Cot : 15 Cot : 15 Cot : 15

LSR2 R7
Cot : 15

LSR3
Cot : 15

LSR4

Tunnel2 Figure 2.2 : Le Traffic Engineering selon MPLS

La souplesse de l'utilisation des labels dans MPLS TE permet de profiter des avantages suivants : Le routage des chemins primaires autour de points de congestion connus dans le rseau (le contournement de la congestion) ; Le contrle prcis du re-routage de trafic, en cas d'incident sur le chemin primaire. (On sous-entend par re-routage : la modification du LSP en cas d'erreur (routeur en panne, manque de ressources)) ; Un usage optimal de l'ensemble des liens physiques du rseau, en vitant la surcharge de certains liens et la sous-utilisation d'autres. C'est ce qu'on appelle l'quilibrage des charges ou load balancing.

Le Traffic Engineering permet ainsi d'amliorer statistiquement les paramtres de QoS (Taux de perte, dlai, gigue, etc.)

Un exemple concret de Traffic Engineering est qu'il est possible de dfinir plusieurs LSP entre chaque couple de LER. Chaque LSP peut tre conu (grce aux techniques de Traffic Engineering) pour fournir diffrentes garanties de bande passante ou de performances. - 18 -

Chapitre II : MPLS Traffic Engineering Ainsi, l'ingress LER pourra placer le trafic prioritaire dans un LSP, le trafic de moyenne priorit dans un autre LSP et enfin le trafic best effort dans un troisime LSP.

2 Calcul et tablissement des "MPLS TE LSP"


Dans un protocole de routage tat de lien (tel que OSPF ou IS-IS), chaque routeur connat tous les routeurs du rseau et les liens qui connectent ces routeurs. Aussi tt qu'un routeur se fait une ide de la topologie du rseau, il excute le "Dijkstra Shortest Path First algorithm" (SPF) pour dterminer le plus court chemin entre lui-mme et tous les autres routeurs du rseau (Construction de la table de routage). Etant donn que tous les routeurs excutent le mme calcul sur les mmes donnes, chaque routeur aura la mme image du rseau, et les paquets seront routs de manire cohrente chaque saut.

Le processus qui gnre un chemin pour un "MPLS TE LSP" est diffrent du SPF classique, mais pas trop. Il y a deux diffrences majeures entre le SPF classique, utilise par les protocoles de routage, et le CSPF (Constrained Shortest Path First), utilis par MPLS TE : Le processus de dtermination de chemin n'est pas conu pour trouver le plus court chemin, mais il tient compte d'autres contraintes ; Il y a plus d'une mtrique chaque nud, au lieu d'une seule comme dans le cas de OSPF et IS-IS.

A remarquer que l'administrateur n'est pas oblig de passer p CSPF pour calculer un ar MPTS TE LSP. Il peut manuellement imposer un chemin explicite une FEC donne. Dans certaines littratures, on appelle les TE LSP calculs par des algorithmes bass sur la situation du trafic des CR-LSP (Constraint-based Routing - LSP), et les TE LSP spcifis explicitement par l'administrateur des ER-LSR (Explicit Routing - LSP).

MPLS cre les LSP diffremment selon qu'on utilise le Traffic Engineering ou non.

La cration d'un "MPLS LSP", dans le cas non TE, suit les deux tapes suivantes : Calcul du "MPLS LSP" : Mise en uvre de l'algorithme SPF (OSPF ou IS-IS). Etablissement du "MPLS LSP" : Mise en uvre d'un protocole de distribution de label Topology-based (LDP, BGP, PIM).

- 19 -

Chapitre II : MPLS Traffic Engineering La cration d'un "MPLS TE LSP" suit les deux tapes suivantes : Calcul du "MPLS TE LSP" : Mise en uvre de lalgorithme CSPF ou intervention manuelle de l'administrateur pour imposer une route explicite. Etablissement du "MPLS TE LSP" : Mise en uvre d'un protocole de distribution de label Request-based (RSVP TE, CR-LDP).

Aprs avoir calculer un chemin avec CSPF, ce chemin doit tre signal travers le rseau, et ceci pour deux raisons : Etablir une chane de labels qui reprsente le chemin ; Rserver les ressources ncessaires (bande passante) travers le chemin.

Dans ce qui suit, on va dtailler l'tape de l'tablissement du "MPLS TE LSP" en examinant de prs le fonctionnement des protocoles de distribution de labels RSVP TE et CRLDP. 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 pour IntServ (C'est un modle de QoS o une machine demande du rseau une QoS donne pour un fux donn). RSVP avec quelques extensions a t adapt par MPLS pour tre un protocole l de signalisation qui supporte MPLS TE.

Nous allons, dans cette partie, commencer par illustrer le format gnral des messages RSVP TE. Pour enfin expliquer avec plus ou moins de dtails le fonctionnement de ce protocole.

- 20 -

Chapitre II : MPLS Traffic Engineering

3.1 Les messages RSVP TE


3.1.1 Les types de messages RSVP TE
Il existe 9 types de messages RSVP TE qui sont rsums dans le tableau 2.1. Type de message Path Resv PathTear Description Utilis pour l'tablissement et le maintien des chemins Envoy en rponse au message Path Analogue au message Path, mais utilis pour supprimer les rservations du rseau Analogue au message Resv, mais utilis pour supprimer les ResvTear rservations du rseau Envoy par un rcepteur d'un message Path qui dtecte une erreur PathErr dans ce message Envoy par un rcepteur d'un message Resv qui dtecte une ResvErr erreur dans ce message Optionnellement envoy l'metteur d'un message Resv pour ResvConf confirmer qu'une rservation donne est bien tablie Analogue ResvConf. Optionnellement envoy l'metteur d'un ResvTearConf message ResvTear pour confirmer qu'une rservation donne est supprime Hello Envoy entre voisins directement connects
Tableau 2.1 : Les messages RSVP TE

3.1.2 Le format des messages RSVP TE


Un message RSVP TE est constitu d'un en-tte commun (commun Header) et d'un nombre variable d'objets selon le type de message (voir figure 2.4).

En-tte MAC

En-tte IP

Message RSVP TE

Figure 2.3 : L'encapsulation des messages RSVP TE

- 21 -

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 Reserved Objects

RSVP checksum RSVP length

Send TTL

Common Header

Figure 2.4 : Format des messages RSVP TE

Version (4 bits) : La version du protocole RSVP. La version actuelle de RSVP est 1. Flags (4 bits) : Encore non dfinit. Message Type (8 bits) : 1 = Path message 2 = Resv message 3 = PathErr message 4 = ResvErr message 5 = PathTear message RSVP Checksum (16 bits) : Utilis pour la dtection d'erreur. Mme principe que pour le champ 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. La valeur de ce champ est donc toujours suprieure 8. 6 = ResvTear message 7 = ResvConf message 10 = ResvTearConf message 20 = Hello message

3.1.3 Le format des objets RSVP TE


Chaque message RSVP TE peut contenir plusieurs objets. Le format gnral d'un objet 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 Object contents

C-type

Figure 2.5 : Format des objets RSVP TE

- 22 -

Chapitre II : MPLS Traffic Engineering Object Length (16 bits) : La longueur de l'objet RSVP en octet, en-tte de l'objet inclus. La valeur de ce champ est donc toujours suprieure 4. Class-Num (8 bits) : La classe de l'objet. C-Type (8 bits) : Le type de classe de l'objet. Object Contents (longueur variable) : L'objet lui-mme.

Chaque classe a son propre espace de numro C-Type. Par exemple, la classe SESSION a 4 C-Types : IPv4, IPv6, LSP_TUNNEL_IPv4, et LSP_TUNNEL_IPv6. Les numros assigns ces C-Types sont 1, 2, 7 et 8. LABEL_REQUEST a 3 C-Types : Without Label Range, With ATM Label Range, and With Frame Relay Label Range. Les numros assigns ces C-Types sont 1, 2, et 3. Ainsi pour identifier le contenu d'un message, on doit prendre en compte les n umros de classe et le numro de C-Type. On peut voir les classes et C-Types comme une sorte du numrotation hirarchique.

3.1.4 Le format des messages Path et Resv


En voici le format des deux principaux messages de RSVP TE ([..] : optionnel) :
Common Header [INTEGRITY] SESSION PHOP TIME_VALUES [EXPLICIT_ROUTE] LABEL_REQUEST [SESSION_ATTRIBUTE] [POLICY_DATA] STYLE SENDER_TEMPLATE SENDER_TSPEC [ADSPEC] [RECORD_ROUTE] FLOWSPEC FILTER_SPEC LABEL [RECORD_ROUTE] Objets Common Header [INTEGRITY] SESSION NHOP TIME_VALUES [RESV_CONFIRM] [SCOPE] [POLICY_DATA]

Figure 2.6 : Format du Path message

Figure 2.7 : Format du Resv message

- 23 -

Chapitre II : MPLS Traffic Engineering Chacun des objets contenus dans un message RSVP TE rempli une fonction de signalisation particulire. Des exemples seront donns dans le paragraphe suivant.

3.2 Le fonctionnement de RSVP TE


RSVP TE est un mcanisme de signalisation utilis pour rserver des ressources travers un rseau. RSVP TE n'est pas un protocole de routage. Toute dcision de routage est faite par IGP (Interior Gateway Protocol). Le seul travail de RSVP TE est de signaler et de maintenir la rservation de ressources travers le rseau. 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 qu'il a besoin de rafrachir priodiquement ses rservations dans le rseau. Ceci est diffrent des "hard-state protocol", qui signalent leurs requtes une seule fois et puis supposent qu'elle reste maintenue jusqu' sa rsiliation explicite. Avec RSVP TE, une requte est rsilie si elle l'est explicitement du rseau par RSVP TE ou si la dure de rservation expire.

3.2.1 L'tablissement et la maintenance des chemins


Bien que l'tablissement et la maintenance des chemins soient des concepts trs proches et utilisent les mmes formats de messages, toutefois, ils diffrent lgrement. C'est pourquoi, on va les expliquer sparment.

L'tablissement des chemins

Aprs que l'ingress LER (appel aussi MPLS TE tunnel headend ou headend) ait termin sa procdure CSPF pour un tunnel particulier, il doit signaler le chemin trouv travers le rseau. Le headend ralise cette opration en envoyant un Path message au prochain saut (next hop) dans le chemin calcul vers la destination. Ce Path message contient un objet EXPLICIT_ROUTE qui contient le chemin calcul par CSPF sous la forme d'une squence de nuds. Le headend ajoute un objet LABEL_REQUEST qui indique qu'une association de label est requise pour ce chemin et quel type de protocole

- 24 -

Chapitre II : MPLS Traffic Engineering rseau sera vhicul sur ce chemin. Enfin, un objet SESSION_ATTRIBUTE peut tre ajout au Path message pour faciliter l'identification de la session et les diagnostics. Finalement, le Path message est achemin vers le l'Egress LER (appel aussi MPLS TE tunnel tail ou tail) en suivant la route spcifie dans l'objet EXPLICIT_ROUTE. Au fur est mesure de l'avancement du Path message, chaque LSR intermdiaire effectue les deux actions suivantes : Il vrifie le format du message pour s'assurer qu'il n'est pas corrompu Il vrifie la quantit de bande passante que le Path message reu demande en utilisant les informations contenues dans les objets SESSION_ATTRIBUTE, SENDER_TSPEC et POLICY_DATA. Ce processus est appel "contrle d'admission". Si le contrle d'admission russit et le Path message est autoris rserver la bande passante qu'il demande, le LSR intermdiaire cre un nouveau Path message et l'envoie au "next hop" (en se rfrant l'objet EXPLICIT_ROUTE).

Les Path messages refont cette procdure avec tous les routeurs du chemin tablir jusqu' atteindre le dernier nud dans l'EXPICITE_ROUTE. Le tunnel tail ralise le contrle d'admission en le Path message, exactement comme n'importe quel nud intermdiaire. Quand le tail ralise qu'il est la destination du Path message, il rpond par un Resv message. On peut considrer le Resv message comme un acquittement (ACK) pour le saut prcdent (Previous Hop, PHOP). Le Resv message n'est pas qu'un acquittement tmoignant de la russite de la rservation, mais il contient aussi le incoming label que le Previous Hop doit utiliser pour l'envoie de paquets de donnes le long du TE LSP jusqu'au tail. En effet, L'objet LABEL_REQUEST (Path message) rclame aux LSR traverss et au tail une association de label pour la session. Le tail rpond au LABEL_REQUEST en incluant un objet LABEL dans son message de rponse RESV. Puis le RESV message est renvoy vers le headend, en suivant le chemin inverse celui spcifi dans l'objet EXPLICIT_ROUTE. Chaque LSR qui reoit le message RESV contenant l'objet LABEL utilisera ce label pour le trafic de donne sortant. Si le LSR n'est pas le headend, il alloue un nouveau label qu'il place dans l'objet LABEL du RESV message, et qu'il fait transiter sur le chemin inverse (grce l'information PHOP qu'il aura mmorise lors du passage du PATH message pendant le processus d'aller). Quand le RESV message arrive au headend, le TE LSP est effectivement cr. A l'issue de la cration de ce LSP, des messages de rafrachissement RSVP TE devront tre mis priodiquement afin de maintenir le LSP cr (soft-state protocol). - 25 -

Chapitre II : MPLS Traffic Engineering Nous allons rsumer le processus d'tablissement des chemins avec l'exemple de la figure 2.8 :

R1
(10) L=18 (1)

R4 R6
(6) L=implicit -null

R2
L=42 (7) (4) (8) L=10921

R7

(5)

R8
(2)

(9) L=21

R3

R5

(3) PATH RESV Figure 2.8 : Path et Resv messages, lors de l'tablissement de chemin

Supposant que R1 a dj ralis sa procdure CSPF et a dj dcid des besoins en bande passante qu'il veut rserver le long du chemin (R1R2R3R5R6R7) : (1) R1 envoie un Path message R2. R2 reoit le Path message, vrifie le format du message et la disponibilit de la bande passante demande par R1. S'il y a un problme, R envoie un message d'erreur (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 mmes vrifications que dans l'tape(1) (3) R3 envoie un Path message R5. Ralisation des mmes vrifications. (4) R5 envoie un Path message R6. Ralisation des mmes vrifications. (5) R6 envoie un Path message R7. Ralisation des mmes vrifications. (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 qu'il veut voir un incoming label 42 dans les paquets de ce tunnel. Ceci veut dire que quand R reoit le label 42, il enlve ce 6 label ( cause de l'implicit-null) et envoie le paquet vers R7. (8) R5 envoie un Resv message R3 et indique qu'il veut voir un incoming label 10921 dans les paquets de ce tunnel. Ceci veut dire que quand R reoit un paquet de donne 5 avec le label 10921, il le change (swapping) en 42 et envoie le paquet vers R6. - 26 -

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 compltement tablie entre R et R7. Le headend (R1) peut alors 1 commencer envoyer les donnes.

La maintenance des chemins

D'un premier coup d'il, la maintenance des chemins et trs similaire l'tablissement des chemins : chaque 30 secondes (Plus ou moins 50%), le headend envoie un Path message par tunnel. Si un routeur envoie quatre Path messages successifs et ne reoit pas de Resv message correspondant, il considre la rservation supprime et envoie un message dans le sens inverse indiquant que la rservation est supprime. Cependant, il y a une chose importante comprendre ici. Path et Resv messages sont tous les deux envoys d'une faon indpendante et asynchrone d'un voisin un autre. Si on regarde encore une fois la figure 2.8, chaque 30 secondes, R envoie un Path message R2 pour la 1 rservation qu'il a effectu. Et chaque 30 secondes, R envoie un Resv message R1 pour la 2 mme rservation. Cependant, les deux messages ne sont pas connects. Un Resv message utilis pour rafrachir une rservation existante n'est pas envoy en rponse un Path message, comme c'est le cas de ICMP Echo Reply qui est envoy en rponse un ICMP Echo Request. On n'a pas de comportement ping/ACK avec Path et Resv messages.

3.2.2 La suppression des chemins


La suppression des chemins est une procdure assez simple. Si un nud dcide qu'une rservation n'est plus ncessaire dans un rseau, il envoie un PathTear le long du mme chemin que le Path message a suivi et un ResvTear le long du mme chemin que le Resv message a suivi. ResvTear messages sont envoys en rponse aux PathTear messages pour signaler que le tunnel tail a supprim la rservation du rseau. Exactement comme les messages de rafrachissement, PathTear messages n'ont pas traverser la totalit du chemin avant que leur effet ne prend place. Dans la figure 2.8, si R 1 envoie un PathTear R2, R2 rpond immdiatement par un ResvTear et puis envoie son propre PathTear au next hop.

- 27 -

Chapitre II : MPLS Traffic Engineering

3.2.3 La signalisation des erreurs


De temps en temps, des problmes peuvent avoir lieu dans le rseau (Bande passante non disponible, boucle de routage, routeur intermdiaire ne prend pas en charge MPLS, message corrompu, cration de label impossible, etc.). Ces erreurs sont signales par PathErr ou ResvErr messages. Une erreur dtecte dans un Path message est traite par un PathErr message, et une erreur dtecte dans un Resv message est traite par un ResvErr message. Les messages d'erreurs sont envoys vers la source de l'erreur ; le PathErr est envoy vers le headend, et un ResvErr est envoy vers le tail.

4 Constraint-based Routing over Label Distribution Protocol (CR-LDP)


Des modifications ont t apportes au protocole LDP pour permettre la spcification du trafic. Ce protocole a t nomm CR-LDP (Constraint-based Routing over Label Distribution Protocol) [4]. L'ide de ce protocole tait d'utiliser un protocole de distribution de label dj existant et de lui ajouter la capacit de grer le Traffic Engineering. Sans entrer dans les dtails de LDP, CR-LDP ajoute des champs ceux dj dfinis dans LDP, tel que "peak date rate" et "committed data rate". Le premier indique le dbit maximum avec lequel un trafic peut tre envoyer via le TE LSP et le deuxime indique le dbit garanti par le domaine MPLS pour ce trafic. La gestion des rservations dans CR-LDP est trs similaire celle utilise dans les rseaux ATM, Alors que RSVP TE utilise plutt le modle de IntServ.

4.1 Les messages CR-LDP


Il y a quatre catgories de message CR-LDP : Discovery messages : utiliss pour annoncer et maintenir la prsence des LSR dans le rseau. Ceci est ralis par l'envoie priodique de messages Hello. Session messages : utiliss pour tablir, maintenir et librer des sessions entre des voisins LDP. Advertisement messages : utiliss pour crer, changer et librer des associations de FEC et LSP.

- 28 -

Chapitre II : MPLS Traffic Engineering Notification messages : utiliss pour vhiculer les informations de supervision. Il y a deux sortes de Notification messages : Error notifications : utiliss pour signaler les erreurs fatales. Quand ces messages sont reus, la session LDP est termine et toutes les associations de labels correspondantes sont annules. Advisory notifications : utiliss pour vhiculer des informations sur la session LDP.

4.2 Le fonctionnement de CR-LDP


On va expliquer d'une faon concise les tapes qui aboutissent l'tablissement d'un CR-LDP LSP. Pour cela, examinant la figure 2.9 :
(1)
LABEL REQUEST (B,C)

(2)
LABEL REQUEST (C)

LSR A Ingress
(5)

LSR B
LABEL MAPPING (17) LABEL MAPPING (32)

LSR C Egress

(4)

(3)

Figure 2.9 : Etablissement d'un CR-LDP LSP

(1) Ingress LSR A dtermine qu'il 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 l'explicit route (B,C) et le dtail des paramtres du trafic ncessaire pour cette nouvelle route. (2) LSR B reoit le LABEL_REQUEST message, rserve les ressources demandes, modifie l'explicit route dans le LABEL_REQUEST message et fait suivre le message LSR C. Si ncessaire, LSR B peut rduire les rservations demandes dans le cas o les paramtres correspondant sont marqus ngociables dans le LABEL_REQUEST message. (3) LSR C dtecte que c'est lui l'egress LSR. Il fait les mmes activits de rservation et de ngociation que LSR B. Il alloue un label pour le nouveau LSR et l'envoie LSR B dans un LABEL_MAPPING message. Ce message contient aussi les dtails des paramtres finaux du trafic pour cet LSP.

- 29 -

Chapitre II : MPLS Traffic Engineering (4) LSR B reoit le LABEL_MAPPING message, il finalise la rservation, 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 mme processus se ralise dans LSR A. Mais vu que LSR A est l'ingress LSR, il n'aura pas allouer un label. Ainsi le nouveau LSR est tabli et les donnes peuvent y transiter. Aujourd'hui dans l'industrie, on trouve que Cisco et Jupiter favorise RSVP TE alors que Nortel favorise CR-LDP. CR-LDP est un hard-state protocol : c'est--dire qu'une fois un LSR est tabli, il restera maintenu jusqu' sa libration explicite. Ce qui n'est pas le cas RSVP TE qui doit priodiquement entretenir ses LSP par des messages de signalisation (soft-state protocol). Cette diffrence permet certain de dire que CR-LDP est plus scalable (rsistant l'augmentation de la taille du rseau), vu que dans le cas de RSVP TE, plus le rseau est tendue plus il sera encombr par des messages de rafrachissement. Malgr ceci, RSVP TE parait tre plus favorable s'imposer comme protocole supportant le Traffic Engineering. Ceci peut s'expliquer par le fait que RSVP est plus ancien que CR-LDP et par consquent plus mature et franc de bugs ; d'autant plus que le constat qu'on a fait sur la scalabilit de ce protocole est trs discutable.

Conclusion
Au terme de ce chapitre, nous avons termin l'tude thorique de la technologie MPLS: nous avons pass en revu son fonctionnement, ses principales composantes et nous avons mis l'accent sur l'application TE. Nous essayerons de montrer, dans les chapitres suivants, l'intrt et de MPLS et son apport pour un oprateur ou un fournisseur de service en terme de "Traffic Engineering".

- 30 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE


Introduction
Le but de ce chapitre est de mettre en vidence les fonctionnalits de MPLS TE en utilisant la simulation comme moyen d'valuation. On va commencer par expliciter les paramtres sur lesquels on va se baser dans notre valuation, savoir les paramtres de Qualit de Service. Ensuite, on va prsenter l'environnement de simulation utilis, pour enfin expliquer la simulation tudie et procder lanalyse des rsultats obtenus.

1 La qualit de service
La qualit de service (QoS) [5] dcrit le niveau de performance attendu d'une application, d'un serveur, d'un rseau ou de tout autre dispositif. Par exemple pour une application, les paramtres principaux envisager pour valuer la QoS sont en gnral la bande passante, le taux de perte en paquets, le dlai de bout en bout et la gigue [6].

1.1 Bande Passante (Bandwidth)

Terminal A 10Mbps 128 kbps 100 Mbps 512 kbps

Terminal B

Figure 3.1 : Illustration du concept de bande passante

Dans l'exemple ci-dessus, La bande passante que peut utiliser le Terminal A pour communiquer avec le Terminal B est simple calculer : c'est la bande passante que peut offrir le plus faible des liens soit 128 kbps. Ceci dans le cas o le rseau est vide. Il en est autrement s'il existe plusieurs flux qui traversent le rseau. Le calcul de la bande passante est d'autant plus complexe qu'il y a de considrations respecter (capacit du lien, nombre de flux et leurs demandes respectives, priorit, rservation pralable, etc.)

- 31 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE

1.2 Perte en paquets (Paquet Loss)


Gnralement, la perte de paquets a lieu lorsque le routeur manque d'espace dans le buffer d'une interface : ainsi, lorsque la file d'attente de sortie d'une interface particulire est sature, les nouveaux paquets qui seront dirigs vers cette interface vont tre rejeter. Les routeurs peuvent rejeter un paquet pour d'autres raisons, par exemple : Le CPU (Central Processing Unit) est congestionn et ne peut p traiter le paquet (la as file d'attente d'entre est sature) ; Le routeur dtecte une erreur dans le paquet (Paquet corrompu) ; Le routeur rejette les paquets les moins prioritaires en cas de congestion dans le rseau. D'autres facteurs peuvent constitus des causes pour la perte de paquets tel que : L'erreur de routage ; La fiabilit du media de transmission.

La perte peut s'exprimer en pourcentage de paquets perdus par rapport aux paquets mis, ou tout simplement en nombre de paquets perdus par unit de temps.

1.3 Dlai de bout en bout (End to End Delay)

Terminal A Dlai de propagation Dlai de propagation Dlai de propagation Dlai de propagation

Terminal B

Dlai de traitement et de mise en file d'attente

Dlai de traitement et de mise en file d'attente

Dlai de traitement et de mise en file d'attente

Figure 3.2 : Illustration du concept de dlai de bout en bout

Le dlai de transmission de bout en bout est le temps coul entre l'mission du paquet et sa rception l'arrive. La figure 3.2 illustre l'impacte qu'a le r seau sur le dlai de bout en bout des paquets transmis d'un Terminal A vers un Terminal B. Chaque saut dans le rseau ajoute un dlai supplmentaire d aux trois facteurs suivant :

Dlai de propagation : C'est le temps que prend la transmission d'un bit via le mdia de transmission (paire torsade, fibre optique, voie radio, etc.) - 32 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE

Dlai de traitement : C'est le temps que consomme un routeur pour prendre un paquet de l'interface d'entre et le mettre dans la file d'attente de l'interface de sortie. Ce dlai dpend de plusieurs facteurs tel que :

La vitesse du CPU ; L'utilisation du CPU ; Le mode de commutation IP (routage IP classique, utilisation de la commutation de label, etc.) ;

L'architecture du routeur ; La taille du paquet.

Dlai de mise en file d'attente : C'est le temps que le paquet passe dans la file d'attente de sortie du routeur. Il dpend du nombre et de la taille des paquets dj dans la file et de la bande passante de l'interface. Il dpend aussi du mcanisme de file d'attente adopt.

Le dlai de bout en bout est la somme de tous les dlais (propagation, traitement et file d'attente) travers le chemin parcouru depuis la source jusqu' la destination. Le dlai de

propagation est fixe (ne dpend que du mdia de transmission), alors que le dlai de traitement et le dlai de mise en file d'attente sont variables (dpendent du trafic).

1.4 Gigue (Jitter)


Cest la variation (en ms) du dlai entre les paquets conscutifs (Voir Figure 3.3). La prsence de gigue dans les flux peut provenir des changements d'intensit de trafic sur les liens de sorties des commutateurs. Plus globalement, elle dpend du volume de trafic et du nombre d'quipements sur le rseau. La gigue affecte les applications qui transmettent les paquets un certain dbit fixe et s'attendent les recevoir au mme dbit (par exemple : voix et vido).

- 33 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE

Emission

Rception

Gigue Figure 3.3 : Illustration du concept de la gigue

1.5 Les exigences des diffrentes applications IP en terme de QoS


Les problmes de qualit de service sont pratiquement inexistants en tlphonie commute ; puisque cette dernire utilise la commutation de circuit qui consiste en l'tablissement d'une connexion physique de bout en bout, ddie chaque paire d'metteurs rcepteurs. Dans le monde IP, La QoS est un passage obligatoire. Car contrairement au rseau tlphonique commut, les rseaux IP vhiculent une multitude d'applications qui diffrent par leurs exigences en terme de QoS. Ces applications concourent pour se partager une quantit de ressources limite offerte par le rseau. C'est pourquoi il est primordial de pouvoir cerner les besoins ncessaires (le besoin minimum) mais aussi suffisants (pas de gaspillage) pour chaque type particulier d'application en terme de QoS.

Type d'application

Bande passante requise Elev

Sensibilit la perte en paquets Moyenne

Sensibilit au dlai Elev

Sensibilit la gigue Elev

Voix (VoIP) Vido (Vidoconfrence) Application interactive (HTTP, jeux en ligne) Best effort (FTP)

Elev

Moyenne

Elev

Elev Non importante Non importante Non importante

Moyenne

Elev

Moyenne

Moyenne

Elev

Faible

Background (mail)

Faible

Elev

Faible

Tableau 3.1 : Les exigences des diffrentes applications IP en terme de QoS

- 34 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE Dans le tableau ci-dessus, il est intressant de remarquer - titre d'exemple - que les applications temps rel (voix, vido) sont trs sensibles au dlai et la gigue, ce qui n'est pas le cas des applications orientes donne. En contre partie, les applications temps rel sont assez tolrantes aux pertes alors qu'une application comme mail ou FTP ne tolre pas du tout les pertes.

2 L'environnement de simulation
2.1 L'intrt dutiliser un simulateur
Les mcanismes utiliss dans les rseaux IP (protocole de routage, file d'attente et dans notre cas MPLS) doivent tre valus afin de mesurer les performances des stratgies utilises et de tester leur fiabilit. L'utilisation d'un rseau rel dans une valuation est difficile et coteuse, en outre de telles valuations ne donnent gnralement pas des rsultats significatifs. Le rseau rel n'offre pas la souplesse de varier les diffrents paramtres de l'environnement et pose en plus le problme d'extraction de rsultats ; c'est pour cela que la majorit des travaux d'valuation de performances utilisent le principe de simulation vu les avantages qu'il offre. En effet, la simulation permet de tester les protocoles sous une varit de conditions. Pour notre projet, nous avons choisi de travailler avec Network Simulator 2 (NS2) .

2.2 Prsentation de NS2


NS ou "Network Simulator" [7] est un simulateur de r seau IP, vnements discrets, orient objet. Cest un projet pilot par lISI (University of Southern California, USA). Il est gratuit, open source, portable et mis jour rgulirement. Il tourne sur plusieurs distributions dUNIX et de Windows. Cest le simulateur le plus utilis dans la communaut scientifique. Il permet lutilisateur de simuler plusieurs communications entre les diffrents nuds dun rseau. Il est bien adapt pour simuler la circulation de paquets dans les rseaux commuts. Il est principalement utilis pour tester des algorithmes de file dattente, de contrle de congestion, des protocoles de transport, des protocoles de routage, le multicast et la mobilit.

- 35 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE La version 1.0 de ce simulateur a t initialement dveloppe au Laboratoire National de Lawrence Berkeley (LBNL). Il fait actuellement partie du projet VINT (Virtual InterNetwork Testbed) sous lequel la deuxime version (NS2) est sortie. Le projet VINT est dirig par luniversit de Californie du sud et est financ par le DARPA en collaboration avec Xerox PARC et LBNL. Il est utilis par plusieurs groupes de travail comme lIETF pour valuer les protocoles en cours de normalisation.

2.3 Fonctionnement de NS2


NS2 est un outil de recherche trs util pour le design, la validation et l'valuation des protocoles. Le simulateur utilise le langage orient objet OTCL driv de TCL pour la description des conditions de simulation sous forme de scripts (Voire figure 3.4). Dans le script, l'utilisateur fournit la topologie du rseau, les caractristiques des liens physiques, les protocoles utiliss, le type de trafic gnr par les sources, les vnements, etc. Si le script crit en OTCL permet une utilisation (dition, modification des simulations) facile du simulateur, les routines -quant elles- sont crites en C++ pour avoir une plus grande puissance de calcul. Ces routines incluent entre autres plusieurs types de protocoles, de files d'attente et d'algorithmes de routage.

- 36 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE

Script OTCL (description de scnario) - Topologie - Caractristiques des nuds - Caractristiques des liens - Protocoles utiliss - Type de trafic gnr - Evnements (envoie de paquet, rupture de liens, changement de mode de routage, etc.) - Etc.

Animation Nam : Visualisation des diffrents vnements du scnario de la simulation.

Simulation Fichier trace : Description textuelle des vnements relatifs la simulation.

Code en C++ (description des routines) - Limplmentation des algorithmes (de routage, de file dattente, ) - Limplmentation des modlisations des liens physiques - Limplmentation de la procdure dencapsulation - Etc.

Filtrage, courbe et analyse des rsultats : (AWK, XGraph, etc.)

Figure 3.4 : Les tapes dune simulation sur NS2

Avant de lancer une simulation, on introduit les paramtres de la simulation dans NS grce aux scripts TCL. Les paramtres consistent notamment en le nombre de n ud, les liens, les protocoles mis en uvre, les diffrents vnements qui vont survenir, etc. Cette phase est en fait une phase de description du scnario de simulation. Les outputs des simulations sont des fichiers textes quon appelle fichiers trace. Ces fichiers sont structurs en entres. Chaque entre correspond une action effectue par un nud (envoie de paquet, rejet de paquet, mise en file d'attente, rception d'un paquet). A titre d'exemple, soit l'entre suivante :

5.213

cbr

500

-------

3.0

0.0

21

305

Cette entre traduit la rception (r) l'instant (5.213)s d'un paquet de type (cbr) de taille (500) octets, de numro d'identit (305), de numro de s quence (21), appartenant au flux (3), transitant entre les n uds (2) et (1), ayant pour adresse source (3.0) (adresse.port) et pour adresse destination (0.0).

- 37 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE

Ces fichiers doivent tre traits pour pouvoir calculer les valeurs de bande passante, perte, dlai et gigue relatives au scnario en question. Par exemple, pour calculer le taux de perte, il suffit de compter les entres commenant par d (drop=rejet) et les entres commenant par r (received=reu), et ainsi extraire le taux de perte. Ce traitement a t ralis par le langage de traitement des fichiers : AWK.

Enfin, le traage des courbes a t ralis par Xgraph.

Par ailleurs, le simulateur permet la cration d'un fichier d'animation permettant de visualiser la simulation sur une interface graphique appele NAM.

2.4 Les modifications apporter NS2


Les simulations ont t faite sur un processeur Intel Pentium III 600MHz, 128Mo de RAM, excutant Linux Red Hat 9.0. La version utilise de NS est 2.26. Cette version ne supporte pas les protocoles relatifs MPLS. On a alors d implmenter un ensemble de modules en extension NS2.26 pour faire de sorte que ce dernier puisse simuler les fonctions MPLS. Les modules ajouts sont les suivants : MPLS Network Simulator (MNS v2.0) Ce module [10] est dvelopp 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 dvelopp par Paolo Losi et mis jour par Sayenko Alexander, Telecommunication laboratory, MIT department, University of Jyvaskyla, Finland.

- 38 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE Il permet de diffrencier les flux en attribuant chaque trafic un poids (weight) qui refltera son niveau de priorit. RSVP/ns Ce module [12] est dvelopp par Marc Greis, Computer Science Department IV, University of Bonn. C'est une implmentation du protocole de rservation de ressource RSVP. RSVP-TE/ns Ce module [13] est dvelopp par Christian Callegari et Fabio Vitucci, Dept. of Information Engineering, University of Pisa, ITALY. Cette implmentation 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 dfaut avec Linux. Cependant, dans la plupart des cas la version qui est livre avec la distribution Linux est soit GCC 2.96, soit GCC 3.x. Le problme c'est que la premire prsente beaucoup de bugs et la deuxime a subi tellement de modifications qu'elle ne supporte plus les modules qu'on va implmenter 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 difficults de NS2


Comme tout outil de simulation, NS2 permet tude de existant, la conception, la l l validation et lvaluation de performances et ceci dans le domaine des protocoles et mcanismes rseau. Cest un simulateur extrmement flexible. NS2 permet ltude des cas difficiles reproduire dans la ralit. Il offre la souplesse de pouvoir varier aisment une multitude de paramtres du rseau (ce qui nest pas le cas si on simule sur un rseau rel). Donc, par rapport lexprimentation sur un rseau rel, NS2 permet un gain de temps et dargent.

- 39 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE Dun autre ct, NS2 souffre des inconvnients des simulateurs tel que la simplification et labstraction du monde rel, la difficult (voire limpossibilit) de tester certains aspects, et la puissance de calcul requise qui croit exponentiellement avec la complexification du systme simul. De plus, NS2 souffre de ltat primitif aussi bien de ses outils de collecte et traitement des rsultats que de son interface graphique. Les concepteurs de NS2 ne manquent pas de mettre en garde les utilisateurs sur l'aspect non achev de ce simulateur. Il ne s'agit pas d'un produit fini, de nouveaux bogues sont souvent trouvs et d'autres constamment introduits par les programmeurs. Finalement, on remarque souvent des problmes d'incompatibilit entre les implmentations de NS, les modules dvelopps pour NS et les versions de linux.

Dans le cas de notre projet, c'est surtout les deux derniers points qui ont prsent une difficult de taille pour l'avancement de notre travail d'autant plus que la documentation manque svrement : gnralement, les modules qui sont d velopps pour NS2 sont en troite dpendance avec les systmes sur lesquels ils ont t dvelopps initialement. De ce fait, il a fallu constamment faire face des problmes d'incompatibilit et de radaptation des modules pour qu'ils puissent fonctionner sur la machine qu'on utilise. On a d passer par une srie de test (implmentation de plusieurs modules, introduction de plusieurs modifications, test de plusieurs combinaisons) et consulter une multitude de documentation concernant la manipulation du systme d'exploitation. Le recours aux forums de discussion et la consultation des auteurs des modules par mail ont t souvent les seuls moyens de surmonter certains problmes. L'tablissement d'une procdure de prise en charge de MPLS RSVP TE par NS2 a consomm beaucoup d'effort et de temps. Et bien qu'elle ne constitue qu'une tape prliminaire pour notre projet ( savoir l'valuation des performances de MPLS TE), elle a comme mme t trs enrichissante du point de vu exprience dans le dbuggage et la manipulation de Linux.

3 Simulation des fonctionnalits de MPLS TE


3.1 Le scnario de simulation
On se propose de mettre en vidence les fonctionnalits de MPLS TE en utilisant RSVP TE comme protocole de distribution de label.

- 40 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE Pour cela, on a adopt une topologie et un scnario qui permet d'expliciter le plus clairement possible le concept de TE. La topologie est constitue de 13 nuds connects comme indiqu sur la figure 3.5.

Figure 3.5 : La topologie de simulation visualis e par NAM

Le scnario est le suivant : Les nuds 0, 1 et 2 sont configurs pour tre des gnrateurs de trafic. Les n uds 11, 12 et 13 sont configurs pour recevoir le trafic, l'analyser et ainsi pouvoir renseigner sur les paramtres mesurer (Bande passante, Perte, Dlai, Gigue). Tous les autres nuds (3..10) sont des LSR configurs pour supporter le protocole RSVP TE. Enfin, tous les liens de la topologie sont dots d'une bande passante de 2Mbps. Les caractristiques des flux qui vont traverser cette topologie sont explicites dans le tableau 3.2 : Nud Nud Taille des paquets (octet) 500 500 500 Dbit (Mbps) 1.8 1.3 0.6 Temps rel (TR) Haute priorit (HP) Best Effort (BE) Couleur dans l'animation NAM Bleu Vert Rouge

Type du trafic

source destination 0 1 2 11 12 13

Tableau 3.2 : Les flux considrs dans la simulation

Le trafic temps rel est gnralement un trafic voix ou vido. Le trafic haute priorit peut vhiculer par exemple une application interactive. Quant au trafic best effort, il peut englober les services mail, transfert de fichier (FTP), etc. - 41 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE Le timing de la simulation est dtaill dans le tableau 3.3 : Instant (s) 0 0.2 6 6 7 9 11 Evnement LSP Dbut de la simulation Dbut de gnration des trafics par les nuds 0, 1 et 2 Activation de la fonction TE pour le nud 0 0_3_4_10_11 (tablissement d'un LSP) Activation de la fonction TE pour le nud 1 1_5_6_7_9_10_12 (tablissement d'un LSP) Activation de la fonction TE pour le nud 2 2_5_6_7_8_10_13 (tablissement d'un LSP) Dsactivation de la fonction TE pour le nud 1 (Libration du LSP) Ractivation de la fonction TE pour le nud 1 (rtablissement du LSP) Provocation d'une rupture dans le lien entre les noeuds 7 et 8. Ce qui provoque une procdure automatique de 2_5_6_7_9_8_10_13 reroutage du trafic venant du nud 2 et l'tablissement d'un nouveau LSP contournant ainsi le lien rompu Fin de la simulation
Tableau 3.3 : Timing de la simulation

13

15

3.2 Rsultats de la simulation et interprtations


La simulation dcrite ci-dessus a permis de tracer des courbes relatives chacun des trois trafics mis en uvre : Le trafic temps rel entre les nuds 0 et 11 Le trafic haute priorit entre les nuds 1 et 12 Le trafic best effort entre les nuds 2 et 13

Pour chacun de ces flux, on va mesurer la variation par rapport au temps des quatre paramtres de QoS savoir : la bande passante, le taux de perte, le dlai de bout en bout et la gigue. On rappel qu'on va utiliser les abrviations suivantes (voir tableau 3.2) : TR : Le flux Temps Rel HP : Le flux Haute Priorit BE : Le flux Best Effort

- 42 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE

3.2.1 "Bande passante" et "Taux de perte en paquets"

Temps rel (TR) Haute priorit (HP ) Best effort (BE)

Figure 3.6 : Bande Passante

Temps rel (TR) Haute priorit (HP ) Best effort (BE)

Figure 3.7 : Taux de paquets perdus

- 43 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE Pour commenter ces courbes, on va procder par intervalles de temps. Chaque intervalle de temps correspondant un vnement particulier (Voir Tableau 3.3).

L'intervalle [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 et 0.6 Mbps pour le BE. On remarque qu' la stabilit, TR a reu une bande passante de 1.2 Mbps, HP a reu 0.6 Mbps et BE a reu 0.2 Mbps (Voir figure 3.6). Ceci correspond un routage classique avec prise en compte des priorits respectives des flux. En effet, le protocole de routage a choisi de faire passer tous les flux par le plus court chemin (5_3_4_10) (Voir figure 3.8). On remarque que la somme des bandes passantes assignes au trois flux est gale 2 Mbps soit la capacit maximale du lien de transmission. La bande passante demande tant plus grande (3.7 Mbps), c'est pourquoi on remarque une saturation de la file d'attente dans le n ud 3 (Voir figure 3.8). La file d'attente est la cause essentielle des pertes en paquets. Les pourcentages de perte sont assez grandes (TR : 33% ; HP : 53% ; BE : 66%) (Voir figure 3.7).

L'intervalle [6s .. 7s]

Figure 3.9 : Situation du trafic entre les instants 6s et 7s

- 44 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE A l'instant 6, RSVP TE tablie un LSP 3_4_10 pour le flux TR et un LSP 5_6_7_9_10 pour le flux HP. Ainsi dans la courbe de bande passante on remarque que ces deux flux ont reu la totalit du dbit qu'ils sollicitent. Ceci induit videment l'annulation de leur taux de perte (Voir Figure 3.7). Le flux BE entrent en comptition pour le mme mdia avec le flux TR, cela dit, il ne reoit que ce qui reste de la bande passante (0.2 Mbps la stabilit) vu que sur ce lien, TR a fait une rservation pralable et est donc prioritaire. Le taux de perte relatif BE reste bien videmment lev. Entre l'instant 6 et 7, on remarque un pic au-del de 1.8 Mbps pour la bande passante de TR. Le dbit supplmentaire provient de la file d'attente qui se vide en laissant la priorit aux paquets relatifs au TR.

L'intervalle [7s .. 9s]

Figure 3.10 : Situation du trafic entre les instants 7s et 9s

A l'instant 7, RSVP TE tablie un LSP 5_6_7_8_10 pour le flux BE. Ainsi BE, bien que partageant une partie du chemin avec HP, a pu satisfaire totalement son exigence en bande passante et avoir un taux de perte nul. Il est intressant ici d'observer la diffrence entre l'acheminement des paquets utilisant le routage classique (Figure 3.8) et l'acheminement des paquets utilisant le Traffic Engineering (Figure 3.10). Cette simulation montre d'une faon explicite que le routage classique ne permet pas une utilisation optimale des liens du rseau : puisque on observe une sur-utilisation de certains liens et une sous utilisation d'autres liens. Ceci provient du fait que les protocoles de routage classiques sont incapables de choisir un chemin autre que le chemin le plus court. Le Traffic Engineering apporte une solution pratique pour ce problme ; puisque, comme c'est dmontr par cette simulation, TE permet un quilibrage de charge optimal sur tous les liens du rseau et une satisfaction totale des exigences des trois trafics en terme de bande passante.

- 45 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE Finalement, entre les instants 7 et 8 et pour le flux BE, on remarque un pic d passant 0,6 Mpbs. Ce dbit supplmentaire provient de la file d'attente du n ud 3 qui contient encore des paquets BE.

L'intervalle [9s .. 11s]

(1)

(2) Figure 3.11 : Situation du trafic entre les instants 9s et 11s

A l'instant 9, on ralise une libration du LSP relatif au trafic HP. Ce flux subit alors un routage classique et empreinte par consquence le chemin le plus court : soit 5_3_4_10 (Voir figure 3.11 (1)). Sur ce chemin, le flux HP n'est servi qu'en deuxime lieu par rapport TR vu que ce dernier a rserv 1.8Mbps sur ce lien. HP se contente alors des 0.2 Mbps qui reste (Voir figure 3.6). En rsultat, on remarque une augmentation de 84% de taux de perte pour HP, schmatis par un dbordement de la file d'attente dans la figure 3.11 (2).

L'intervalle [11s .. 13s]

Figure 3.12 : Situation du trafic entre les instants 11s et 13s

En ractivant le TE pour HP on retrouve le rquilibrage des charges sur les liens du rseau et un vidage progressif de la file d'attente dans le n ud 3 (Ce qui explique encore une fois le pic entre les instants 11 et 12 pour le trafic HP (Voir figure 3.6).

- 46 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE

L'intervalle [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 la bande passante (Voir figure 3.6) et une augmentation consquente du taux de perte (Voir figure 3.7). Juste aprs, il y a eu tablissement d'une nouvelle LSP (Voir figure 3.13 (2)) permettant de nouveau un quilibrage optimal des charges sur le rseau. En attendant que RSVP TE termine la procdure de reroutage, le flux BE a subi un routage classique (Voir figure 3.13 (1)). Cette simulation a permis ainsi de mettre en vidence la robustesse de MPLS TE face aux pannes.

- 47 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE

3.2.2 "Dlai de bout en bout" et "Gigue"

Temps rel (TR) Haute priorit (HP ) Best effort (BE)

Figure 3.14 : Dlai de bout en bout

Figure 3.15 : Gigue relatif au trafic TR

- 48 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE

Temps rel (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 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE

L'intervalle [0.2s .. 6s]


Dans cet intervalle le dlai est presque identique pour les 3 flux (TR : 90ms ; HP,BE : 100ms). TR profite d'un dbit meilleur parce qu'il est privilgi dans la file d'attente. La gigue est stable (RT : jusqu' ms, HP : jusqu' 2.2ms, BE : jusqu' 1.0ms). La

prsence de la gigue est due essentiellement la file d'attente dans le nud 3. Elle est trs faible pour TR, ce qui traduit sa priorit dans la file par rapport aux autres flux. Elle est assez constante pour l'ensemble des trafics, ce qui traduit la rgularit de la satisfaction des trois flux.

Figure 3.18 : Zoom relatif la courbe de gigue

L'intervalle [6s .. 7s]


L'tablissement de LSP pour TR et HP a f que leur dlai de bout en bout s'est nettement ait amlior (amlioration de 30ms pour HB et de 40ms pour TR (voir figure 3.14)). Le flux BE voit sont dlai augmenter exponentiellement vu qu'il empreinte un chemin rserv par TR. En ce qui concerne HP, l'amlioration de la gigue est nette (0.1ms au lieu de 2.2ms). On peut mme dire que ce trafic ne prsente pas de gigue, puisque il est seul sur le chemin qu'il emprunte. La gigue relative BE atteint 5ms, vu que TR est prioritaire par rapport BE. L'amlioration du dlai relatif TE n'a pas empch sa gigue d'augmenter de 0.2ms. Mais une telle augmentation n'a pas d'incidence sur les applications temps rel.

L'intervalle [7s .. 9s]


L'tablissement d'un LSP pour le flux BE a amlior son dlai qui est devenu gal celui de HP (70ms), puisque ces deux trafics empruntent des LSP de mme longueur.

- 50 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE

Figure 3.19 : Zoom relatif la courbe de dlai entre les instant 8.5s et 8.85s

On remarque sur la courbe des dlais la prsence d'une petite variation priodique relatif aux flux HP et BE (Voir figure 3.19). Ceci est d au fait que ces deux trafics empruntent des chemins scants. C'est ce qui explique la lgre augmentation de la gigue relative HP (jusqu' 0.4ms) Pour le trafic TR, on remarque que la gigue reste la m me jusqu' l'instant 7.5, vu que la file d'attente du n ud 3 contient encore des paquets BE. A partir de 7.5, la file devient vide et la gigue disparat pour le trafic TR.

L'intervalle [9s .. 11s]


La dsactivation du LSP de HP fait qu'il est rout s le mme chemin que TR. Or TR a ur rserv sont chemin donc il est prioritaire. C'est pourquoi son dlai est rest le mme. Cela dit, la courbe de dlai relative TR n'est plus constante mais oscille lgrement autour de sa moyenne (Voir figure 3.14). Ceci est d au partage du mdia avec le flux HP. Il en rsulte une augmentation faible de la gigue de TR (0.3ms). HP n'est servi qu'en dernier lieu. Son dlai augmente alors exponentiellement pour atteindre 460ms, et sa gigue se dtriore pour atteindre 0.9ms. La gigue du trafic BE s'est bien sr amliore puisque BE utilise seul le mdia.

L'intervalle [11s .. 13s]


Le rtablissement du LSP de HP a rtabli les paramtres leur tat initial.

L'intervalle [13s .. 15s]


Jusqu' l'instant 13,2s, BE observe une augmentation brusque du dlai et de la gigue. Ceci est d la rupture du lien entre les nuds 7 et 8 et au temps que prend la procdure de reroutage (recherche et tablissement d'un nouveau LSP optimal).

- 51 -

Chapitre III : Implmentation et simulation des fonctionnalits de MPLS TE Cette panne a profit pour HP dont la gigue s'est amliore pendant ces 0.2s. Le contraire s'est produit pour TR qui a d partager les liens qu'il utilise avec BE pendant la dure de reroutage. A partir de l'instant 13.2, on observe une re-stabilisation des dlais avec une augmentation de 10ms pour le flux BE vu que le nouveau LSP est plus long. Cette augmentation n'est pas handicapante surtout que ce trafic est un Best Effort.

Il est intressant de remarquer que, durant toute la priode de simulation, la gigue relative au flux TR ne dpasse jamais 0.3ms. Ceci est trs important pour un trafic temps rel (voix, vido). HP et BE atteignent parfois les 5ms de gigue mais a n'a pas grande importance vu la nature de leurs applications.

Conclusion
Les simulations que nous avons ralises ont mis en vidence le besoin d'intgrer des mcanismes aux rseaux IP actuels pour pouvoir supporter les trafics multiservice et respecter les exigences propres chaque type d'application. MPLS TE est une solution qui s'est monte efficace et surtout simple mettre en uvre et trs souple manipuler. Elle permet de raliser un quilibrage de charge sur l'ensemble du rseau et de prendre des dcisions de re-routage ; ce qui se traduit par une utilisation plus optimale des ressources et une satisfaction plus grandes des demandes des applications.

- 52 -

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Tlcom"

Chapitre IV : Evaluation des performances de MPLS TE sur le backbone de "Tunisie Tlcom"


Introduction
On a dj voqu les avantages conomiques qu'implique l'exploitation d'un seul rseau pour plusieurs applications, et le gain qui pourra rsulter du remplacement de la commutation de circuit par la commutation de paquet. En suivant cette logique, Tunisie Tlcom s'est fix le but d'avoir (dans le court/moyen terme) un rseau national unique pour vhiculer la fois le trafic voix ( ce jour ralis par un rseau commutation de circuit) et le trafic de donne (ralis par la commutation de paquet et/ou de cellule). Ceci vient en conformit avec la logique de baisse des tarifications des Tlcom. De plus, migrer vers un tel rseau permettra d'offrir une infrastructure plus encourageante l'informatisation des entreprises et des particuliers. Ce qui contribuera l'instauration de la "Socit de l'Information".

On a vu dans le chapitre III qu'il est invitable de passer par le "Traffic Engineering" pour optimiser l'utilisation d'un rseau afin qu'il soit apte vhiculer du multiservice. C'est pourquoi, dans ce chapitre, on va essayer d'valuera l'apport de la technologie MPLS TE sur le backbone de Tunisie Tlcom, ceci en utilisant la simulation sur NS2 comme outil d'tude.

1 Description du backbone MPLS de Tunisie Tlcom


1.1 Dfinition de Backbone
Un backbone est un ensemble d'artres longues distances, trs haut dbit de transmission, qui relient les principaux nuds d'un rseau tendu. Le backbone constitue le cur du rseau, sur lequel des liaisons de plus faibles capacits de transmission sont raccordes. Ces liaisons servent interconnecter des rseaux plus petits (internes une

- 53 -

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Tlcom"

entreprise ou une rgion). On peut faire l'analogie des petits rseaux se rattachant un backbone, avec des rivires qui viennent grossir le cours d'un fleuve. Les liens qui forment le backbone sont constitus majoritairement de cbles fibres optiques installs sous les ocans et sur les continents. On distingue les rseaux backbone nationaux (chelle d'un pays), rgionaux (chelle d'un groupe de pays) ou mondiaux (chelle de la plante). Dans notre cas, on s'intressera au backbone national de Tunisie Tlcom.

1.2 Structure du backbone de Tunisie Tlcom


Le backbone qu'on va utilis comme base pour nos simulations est le suivant :

18 LER 9 LSR

Figure 4.1 : La structure du backbone de Tunisie Tlcom

Il est constitu de : 9 LSR : Quatre se trouvent dans le grand Tunis et plus prcisment Kasbah, Hached, Belvdre et Ouardia ; Cinq sont dans les villes de Sfax, Sousse, Bja, Kairouan et Gabes.

18 LER : Neuf sont co-localiss 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 la commodit de la reprsentation, on schmatisera chaque couple LSR/LER co-localis par un seul routeur.

- 54 -

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Tlcom"

La figure 4.2 montre la disposition gographique du backbone.


Grand Tunis Nabeul Bja

Bizerte

Kairouan

Sousse

Moknine

STM-4
Sfax

LER 2 STM-4 LER/LSR STM-16

Gafsa Gabs

Figure 4.2 : La disposition gographique du backbone de Tunisie Tlcom

Pour mieux apprcier cette topologie, on va plutt considrer la disposition de la figure 4.3 :
Marsa Ben Arous Nabeul Bizerte Moknine

Ouardia Bja Hached Sousse Menzeh

Belvdre

Sfax Kairouan Kasbah

Gabs Ariana Bardo Figure 4.3 : Backbone de Tunisie Tlcom Gafsa

- 55 -

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Tlcom"

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 nuds MPLS du backbone reoit un "flux voix" et un "flux donne". Le tableau 4.1 illustre les capacits des liens raccords au backbone selon le type de trafic qu'ils vhiculent : Site Ariana Bardo Bja Belvdre Ben Arous Bizerte Hached Kairouan Kasbah Marsa Menzeh Moknine Nabeul Ouardia Sfax Sousse Gabs Gafsa Capacit du lien ddi au trafic "Voix" (Gbps) 1 1 1 2 2 1 2 1 2 2 1 1 2 2 2 2 1 1
Tableau 4.1 : Descriptif des liens raccords au backbone

Capacit du lien ddi au trafic "Donne" (Gbps) 2 3.1 1.1 2 5 1.6 2 1.1 1.1 1 2 1 3.3 2 4.9 3.5 1 0.9

- 56 -

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Tlcom"

2 Simulation et rsultats
2.1 Scnario de la simulation
Afin d'valuer l'apport de la technologie MPLS TE sur le backbone de Tunisie Tlcom, Nous avons procd l'implmentation de la topologie sur NS2 (Voir Figure 4.4).

Figure 4.4 : le backbone tel que gnr par NS2

La modlisation des distances :


La transmission des donnes sur fibre vrifie la loi : c = Avec c : clrit = 3 108 m/s d : longueur de la fibre t : dlai de propagation
d t

Ainsi, pour avoir 1ms de dlai de propagation, il faut 300Km de fibre. Or dans le backbone tudi, es deux nuds les plus loigns et qui sont directement lis sont 406Km l (Hached-Gabs). Etant donne que le dlai de bout en bout est gnralement de l'ordre de plusieurs dizaines de ms, le dlai de propagation (qui constitue une des composantes du dlai de bout en bout) peut tre nglig dans la simulation. Donc, au niveau du territoire national, les distances n'ont pas grande influence sur le dlai de bout en bout.

Description du trafic simul :


On configure certains nuds du backbone pour qu'ils gnrent deux types de trafics : Un trafic voix dont le d bit est quivalent au quart (1/4) de la capacit du lien ddi au trafic "Voix" entrant au backbone (Voir Tableau 4.1) ; Un trafic donne dont le dbit est quivalent au tiers (1/3) de la capacit du lien ddi au trafic "Donne" entrant au backbone (Voir Tableau 4.1) ;

- 57 -

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Tlcom"

Chaque trafic entrant (voix et donne) est vhicul travers le backbone vers les diffrents LER.

2.2 Rsultats et interprtations


2.2.1 Estimation des charges des liens constituant le backbone
On se propose d'estimer l'occupation de chaque lien du backbone. L'occupation d'un lien sera exprime en pourcentage de la bande passante utilise. En d'autres termes :

Occupation d' un lien =

Dbit envoy sur ce lien Bande Passante du lien

Par exemple, si on envoie un dbit de 155.52Mbps sur un lien STM-4 (ayant une bande passante de 622.08Mbps), on aura une occupation de lien de 25%.

Le tableau 4.2 rsume l'ensemble des mesures effectues sur l'occupation des liens. Les mesures ont t faites : Une premire fois avec le backbone fonctionnant en mode IP classique ; Une deuxime fois avec le backbone fonctionnant en mode MPLS TE.
Occupation du lien (%) Mode Mode IP classique MPLS TE 56 62 54 77 58 63 55 68 45 66 46 68 38 70 35 69 88 90 85 96 59 76 62 90 54 76 50 53 36 80 32 75

Lien Bardo Bardo Ariana Ariana Menzeh Menzeh Marsa Marsa Ben Arous Ben Arous Nabeul Nabeul Bizerte Bizerte Moknine Moknine Belvdre Kasbah Belvdre Kasbah Hached Belvdre Hached Ouardia Hached Ouardia Ouardia Sousse Ouardia Bja Sousse Sfax

Type du lien 2 STM-4 2 STM-4 2 STM-4 1 STM-4 2 STM-4 2 STM-4 2 STM-4 1 STM-4 2 STM-4 2 STM-4 2 STM-4 2 STM-4 2 STM-4 1 STM-4 2 STM-4 1 STM-4

- 58 -

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Tlcom" Gafsa Gafsa Hached Ouardia Kasbah Belvdre Hached Hached Hached Belvdre Belvdre Kasbah Kasbah Ouardia Ouardia Sfax Sfax Sfax Kairouan Bja Sfax Gabs Ouardia Kasbah Belvdre Hached Kasbah Sfax Gabs Ouardia Sousse Sfax Kairouan Sousse Bja Gabs Kairouan Sousse Sousse Kairouan 2 STM-4 2 STM-4 1 STM-4 1 STM-4 1 STM-4 1 STM-4 1 STM-16 1 STM-16 1 STM-16 1 STM-16 1 STM-16 1 STM-16 1 STM-16 1 STM-16 1 STM-16 1 STM-16 1 STM-16 2 STM-4 /1 STM-16 2 STM-4 1 STM-4 / 1 STM16
Tableau 4.2 : L'occupation des liens

35 48 100 100 100 100 95 98 100 100 100 96 100 100 100 87 83 100 100 77

70 83 81 79 85 74 88 86 84 90 91 97 92 89 93 76 88 92 83 70

Ce tableau, prsent ainsi, n'est pas trs parlant. Pour cela, on a rapport ces mesures directement sur le schma du backbone, en utilisant un code couleur appropri (Voire Figure 4.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 -

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Tlcom"

La figure 4.6 traduit un certain quilibrage des charges sur tout le backbone et du coup une utilisation plus optimale des ressources du rseau (presque tous les liens sont orange). Cette performance a t rendue possible grce l'utilisation du Traffic Engineering.

La figure 4.5 montre l'existence de plusieurs liens saturs, alors que d'autres liens sont sous-utiliss. Ceci s'explique par le fait que le routage IP classique ne prend pas en considration les capacits disponibles des liens, puisque son seul critre est la recherche du plus court chemin. Donc, pour router les paquets, il a tendance sur-utiliser les nuds LER/LSR et donc saturer les liens STM-16 bien qu'il aurait pu utiliser des routes videment plus longues et de plus fiables capacits - mais ayant de la bande passante non utilise. Voyant ceci sur un cas de figure :

Supposant qu'on a un trafic envoyer depuis le LER Moknine vers le LER Ariana. Le chemin le plus court sera de passer par Sousse et Belvdre travers un lien STM-16 (Voir Figure 4.7). Ce lien grande chance d'tre satur. Ce qui se traduira pour le trafic de Moknine par des pertes et des dlais trs importants.
Moknine

Sousse

Belvdre

Ariana

Figure 4.7 : Exemple de route IP

D'un autre ct, des liens rattachant des nuds comme Nabeul et Ben Arous peuvent tre partiellement disponibles et donc peuvent vhiculer le trafic de Moknine jusqu' Ariana (Voir Figure 4.8).

- 60 -

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Tlcom"

Ben Arous

Nabeul Moknine

Sousse Hached Ouardia

Belvdre

Ariana

Figure 4.8 : Exemple de route MPLS TE

IP classique est incapable de prendre une dcision de re-routage de trafic travers une route plus longue mme si elle est plus disponible. Tout ce qu'il peut faire, c'est mettre les paquets sur file d'attente 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 dlai


On va essayer d'apprcier l'impacte que peut avoir l'utilisation de MPLS TE sur le paramtre dlai. Pour cela, on va mesurer "le dlai normalis par le nombre de saut". C'est-dire que pour chaque paquet reu, on mesure son dlai de bout en bout puis en divise par le nombre de saut qu'il a effectu depuis la source jusqu' la destination. En d'autres termes :

Dlai normalis par le nombre de saut =

Dlai de bout en bout Nombre de Saut

Ce paramtre reflte en ralit le temps de sjour moyen d'un paquet dans une file d'attente (puisque le dlai de propagation et les autres composantes du dlai sont ngligeables).

La figure 4.9 reprsente les courbes relatives aux dlais. Les mesures ont t faites : Une premire fois avec le backbone fonctionnant en mode IP classique : Dans ce cas les trafics Voix et Donne sont traits de la mme manire, puisqu'il n'y a pas un

- 61 -

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Tlcom"

mcanisme de classification. C'est pour a qu'on a reprsent une seule courbe de dlai pour les deux trafics (courbe bleu). Une deuxime fois avec le backbone fonctionnant en mode MPLS TE : Dans ce cas, on a un traitement diffrent du trafic Voix et du trafic Donne. Donc on a reprsent deux courbes de dlai relatives chacune un type de trafic (courbe rouge et verte).

Trafic - mode IP Trafic Donne mode MPLS TE Trafic Voix mode MPLS TE

Figure 4.9 : Dlai normalis par le nombre de saut

On remarque que pour le mode IP, on a un d qui varie autour de 70ms. Lorsqu'on lai passe au mode MPLS TE, on observe une diffrence nette entre le dlai moyen du trafic Donne et le dlai moyen du trafic Voix. Le trafic Voix observe une chute de dlai considrable pour atteindre une moyenne de 35ms. Cette valeur est assez satisfaisante pour le transfert de la voix. Puisque en regardant le backbone, on s'aperoit que les deux destinations les plus loignes sont distantes de 4 sauts. Donc si le processus MPLS TE privilgie le trafic Voix et lui assigne assez souvent le plus court chemin, ce trafic aura un dlai de bout en bout ne dpassant pas les 140ms (35*4). Ce qui est acceptable en tlphonie vu qu'on tolre jusqu' 150ms de dlai.

Quant au trafic Donne, sont dlai augmente jusqu' une moyenne de 105ms. Ce qui n'est pas trs handicapant pour les services Donne

D'un autre ct, il est intressant de remarquer qu'en passant vers le mode MPLS TE, la marge de fluctuation des courbes de dlai a diminu considrablement surtout pour le trafic Voix. Ceci traduit l'quilibrage des charges dans les files d'attente

- 62 -

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Tlcom"

2.2.3 Estimation du taux de perte


Pour l'estimation des pertes, on a suivi la mme approche que pour le dlai. Et on a pu tracer trois courbes relatives : au trafic en utilisant le routage IP classique ; au trafic Voix en utilisant MPLS TE ; au trafic Donne en utilisant MPLS TE.

Trafic - mode IP Trafic Donne 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 pertes sont dues la saturation de certains liens du backbone (Voir Figure 4.5). Un tel taux de perte ne permet pas de vhiculer correctement le trafic Voix, puisqu'en tlphonie le seuil maximum permis est de 2%. Le taux de perte est presque nul lorsque le rseau utilise le mode MPLS TE. Ceci est conforme au rsultat obtenu pour l'estimation des charges des liens, puisque ces derniers sont tous non saturs (Voir Figure 4.6).

Conclusion
Les simulations que nous avons ralises sur le backbone de Tunisie Tlcom ont permis de mettre en vidence plusieurs constats : d'abord, il est vident que le routage IP classique n'est pas du tous appropri pour vhiculer du multiservice. Ensuite, MPLS TE est une approche qui s'est montre trs performante quant l'optimisation de l'utilisation des ressources du rseau, d'autant plus qu'elle permet la transmission de trafic multiservice en respectant les exigences des diffrentes applications.

- 63 -

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Tlcom"

Enfin, il est intressant de remarquer qu'un taux de perte de 0% dpasse de loin les paramtres dont on a besoin. Donc on pourra penser par exemple diminuer le nombre de liens dans le backbone au risque d'augmenter le taux de perte, sans dpasser les seuils des exigences respectives des applications. Et ainsi raliser des gains conomiques.

- 64 -

Conclusion gnrale

Conclusion gnrale
L'objectif de ce projet de fin d'tude est l'analyse des performances de MPLS en terme de "Traffic Engineering". Nous avons abord cette thmatique en commenant par une tude thorique de la technologie MPLS. Pour cela, nous avons tudi dans le Chapitre I le principe de fonctionnement de MPLS, nous avons fait le tour des concepts relatifs ce dernier et prsent les applications qu'il permet de raliser. Dans le chapitre II, nous nous sommes penchs sur l'une des plus importantes applications de MPLS savoir la prise en charge du "Traffic Engineering" et nous nous sommes concentrs dans cette partie sur l'tude du protocole de distribution de label RSVP TE. Ceci nous a prpar la deuxime phase de ce projet qui est la simulation du fonctionnement de MPLS. Nous avons pour cela prparer l'environnement de simulation NS2 pour qu'il soit capable de prendre en charge les mcanismes et protocoles relatives MPLS (en particulier RSVP TE). Ainsi, nous avons dans le chapitre III, russi implmenter un rseau MPLS et simuler quelques unes de ses fonctionnalits telles que la cration de LSP, la rservation de ressources ou le re-routage en cas de pannes. Nous avons aussi ralis un ensemble de mesures qui ont permis d'aboutir aux conclusions suivantes : D'abord, contrairement l'IP classique, MPLS TE privilgie le choix des chemins disponibilit suffisante plutt que les chemins les plus courts. Les courbes de Bande passante, perte, dlai et gigues que nous avons dresses ont montr le bien fond de cette approche. Ensuite, MPLS TE permet de garantir une qualit de service minimale une application donne grce au mcanisme de rservation de ressource qu'opre RSVP TE sur les LSP qu'il construit. Puis, nous avons mis en vidence la robustesse de MPLS TE face aux pannes qui peuvent survenir dans le rseau grce sa fonction de re-routage. Enfin, On peut affirmer que MPLS TE permet d'atteindre un haut niveau d'optimisation de rseau et de satisfaire ainsi plus efficacement les demandes des applications rendant possible de vhiculer plusieurs types de trafic sur un rseau IP.

Dans le chapitre IV, nous avons essay d'valuer l'apport qu'aura l'intgration de l'approche TE dans le backbone de Tunisie Tlcom. Nous avons montr que le routage

- 65 -

Conclusion gnrale classique ne permet pas de vhiculer voix et donne sur le mme rseau. Alors qu'en utilisant le TE on a pu raliser un certain quilibrage de charges sur les liens du backbone et ainsi amliorer nettement les paramtres de perte et de dlai. Le "Traffic Engineering" ralise une rpartition plus fine des ressources dans le rseau de l'oprateur permettant d'un ct dviter le recours une politique de surdimensionnement des rseaux physiques et d'un autre ct dassocier voix/donn sur le mme backbone

On propose comme travail complmentaire de raliser une application d'optimisation du rseau base sur des algorithmes mta-heuristiques. On imposera comme contraintes : Les seuils de QoS (dlai, perte, gigue, etc.) permis pour chaque type de trafic ; Les capacits des liens ; Les statistiques relatives au trafic national.

On aura comme rsultat un cblage optimal du backbone MPLS avec un maximum d'conomie sur les liens.

Plusieurs autres domaines et axes de recherche intressants lis cette technologie restent 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 l'association Diffserv - MPLS ; L'amlioration des mcanismes de files d'attente utiliss ; MPLS VPN ; GMPLS, qui est une gnralisation de MPLS pour supporter les rseaux optiques.

- 66 -

Rfrences

Rfrences
[1] Jean-Louis Mlin, Qualit de service sur IP, Eyrolles, 2001 [2] Jean-Antoine Montagnon, T Huong Tran, MPLS et les rseaux dentreprise, ONX/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 Ahn's homepage, http://flower.ce.cnu.ac.kr/~fog1/mns/ [11] Alexander Sayenko homepage, http://www.cc.jyu.fi/~sayenko/ [12] RSVP\ns homepage, http://titan.cs.uni-bonn.de/~greis/rsvpns/index.html [13] RSVP-TE\ns homepage, http://netgroup-serv.iet.unipi.it/rsvp-te_ns/

- 67 -

Rsum Le principe de "Best Effort" ne peut offrir aucune garantie de QoS pour les exigences des nouvelles applications (vido, voix, etc). En mme temps, il ne serait pas raisonnable d'abandonner les rseaux IP qui sont tellement rpandus de nos jours. MPLS apporte une solution ingnieuse ce problme et rend ainsi possible le multiservice sur les rseaux IP. Cette technologie a russi conjuguer la simplicit de IP avec la gestion de QoS d'ATM. MPLS a permis entre autres de raliser des applications comme le "Traffic Engineering" qui permet d'accder un haut niveau d'optimisation des rseaux, facilitant ainsi le passage au "tout IP".

Mot cls MPLS, Traffic Engineering, commutation de label, RSVP TE.