77
RAPPORT DE PROJET DE FIN D’ETUDES Filière Ingénieurs en Télécommunications Option Ingénierie des réseaux Analyse des performances de MPLS en terme de "Traffic Engineering" dans un réseau multiservice Elaboré par : Oussama FOUDHAILI Encadré par : M. Rached HAMZA M. Jamel SAKKA Année universitaire : 2004/2005

Mpls foudhaili oussama

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Mpls foudhaili oussama

RAPPORT DE PROJET DE FIN D’ETUDES

Filière

Ingénieurs en Télécommunications

Option

Ingénierie des réseaux

Analyse des performances de MPLS

en terme de "Traffic Engineering" dans

un réseau multiservice

Elaboré par :

Oussama FOUDHAILI

Encadré par :

M. Rached HAMZA

M. Jamel SAKKA

Année universitaire : 2004/2005

Page 2: Mpls foudhaili oussama

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

Page 3: Mpls foudhaili oussama

Remerciements

Je tiens tout d’abord à remercier Monsieur Rached Hamza (Sup'Com) pour

m'avoir fait l'honneur d'être mon encadreur. J'adresse également mes très vifs

remerciements à Monsieur Jamel Sakka (Tunisie Télécom) pour sa compétence, 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'accès à une formation qui m'a permis

de m'améliorer scientifiquement et humainement.

Une pensée amicale est adressée à mes amis Kamel Zidane et Anis Souissi

avec qui j'ai partagé le même foyer pendant trois ans et dont la présence 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 nommés ici, mais qui ont contribué

de prés ou de loin au bon déroulement de ce projet, trouvent l'assurance de ma pleine

gratitude.

Oussama Foudhaili

Page 4: Mpls foudhaili oussama

- i -

Table des Matières

Introduction Générale 1 Capitre I : MultiProtocol Label Switching (MPLS) 3

Introduction.................................................................................................................3 1 Principe de fonctionnement de MPLS .....................................................................3 2 Les labels .................................................................................................................5 3 Pile de labels (Label Stack) .....................................................................................7 4 Concepts relatifs à la distribution de labels .............................................................8

4.1 Contrôle de distribution des labels ....................................................................8 4.2 Distribution et gestion des labels ......................................................................8 4.3 Conservation des labels .....................................................................................9 4.4 Espace de labels (Label Space) .........................................................................9 4.5 Création des labels ..........................................................................................10 4.6 Modes de fonctionnement de quelques protocoles de distribution de label....11

5 Les applications de MPLS .....................................................................................12 5.1 Any Transport over MPLS (AToM) ...............................................................13 5.2 Le support des réseaux privés virtuels (MPLS VPN) .....................................13 5.3 Le support de la qualité de service (MPLS QoS)............................................15 5.4 Le Traffic Engineering (MPLS TE)................................................................15

Conclusion................................................................................................................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

Page 5: Mpls foudhaili oussama

- ii -

Capitre III : Implémentation et simulation des fonctionnalités de MPLS TE 31

Introduction...............................................................................................................31 1 La qualité de service ..............................................................................................31

1.1 Bande Passante (Bandwidth)...........................................................................31 1.2 Perte en paquets (Paquet Loss)........................................................................32 1.3 Délai de bout en bout (End to End Delay) ......................................................32 1.4 Gigue (Jitter) ...................................................................................................33 1.5 Les exigences des différentes applications IP en terme de QoS .....................34

2 L'environnement de simulation..............................................................................35 2.1 L'intérêt d’utiliser un simulateur .....................................................................35 2.2 Présentation de NS2 ........................................................................................35 2.3 Fonctionnement de NS2 ..................................................................................36 2.4 Les modifications à apporter à NS2 ................................................................38 2.5 Avantages, limites et difficultés de NS2 .........................................................39

3 Simulation des fonctionnalités de MPLS TE.........................................................40 3.1 Le scénario de simulation................................................................................40 3.2 Résultats de la simulation et interprétations ....................................................42

3.2.1 "Bande passante" et "Taux de perte en paquets" ......................................43 3.2.2 "Délai de bout en bout" et "Gigue"...........................................................48

Conclusion................................................................................................................52 Chapitre IV : Evaluation des performances de MPLS TE sur le backbone de "Tunisie

Télécom" 53

Introduction...............................................................................................................53 1 Description du backbone MPLS de Tunisie Télécom...........................................53

1.1 Définition de Backbone ...................................................................................53 1.2 Structure du backbone de Tunisie Télécom....................................................54

2 Simulation et résultats............................................................................................57 2.1 Scénario de la simulation ................................................................................57 2.2 Résultats et interprétations ..............................................................................58

2.2.1 Estimation des charges des liens constituant le backbone ........................58 2.2.2 Estimation du délai ...................................................................................61 2.2.3 Estimation du taux de perte.......................................................................63

Conclusion................................................................................................................63 Conclusion générale 65 Références 67

Page 6: Mpls foudhaili oussama

- iii -

Table des figures

Figure 1.1 : Exemple d'un réseau MPLS .......................................................................3

Figure 1.2 : l'encapsulation MPLS dans différentes 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 délai de bout en bout.......................................32

Figure 3.3 : Illustration du concept de la gigue ...........................................................34

Figure 3.4 : Les étapes d’une simulation sur NS2 .......................................................37

Figure 3.5 : La topologie de simulation visualisée 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 : Délai de bout en bout ..............................................................................48

Figure 3.15 : Gigue relatif au trafic TR .......................................................................48

Page 7: Mpls foudhaili oussama

- iv -

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 délai entre les instant 8.5s et 8.85s.............51

Figure 4.1 : La structure du backbone de Tunisie Télécom.........................................54

Figure 4.2 : La disposition géographique du backbone de Tunisie Télécom..............55

Figure 4.3 : Backbone de Tunisie Télécom .................................................................55

Figure 4.4 : le backbone tel que généré 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 : Délai 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 différentes applications IP en terme de QoS ............34

Tableau 3.2 : Les flux considérés dans la simulation ..................................................41

Tableau 3.3 : Timing de la simulation .........................................................................42

Tableau 4.1 : Descriptif des liens raccordés au backbone ...........................................56

Tableau 4.2 : L'occupation des liens ............................................................................59

Page 8: Mpls foudhaili oussama

- v -

Acronymes

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

Page 9: Mpls foudhaili oussama

- vi -

PHOP Previous Hop PIM Protocol Independent Multicast PPP Point-to-Point Protocol QoS Quality of Service RIP Routing Information Protocol RSVP TE Resource ReSerVation Protocol - Traffic Engineering SDH Synchronous Digital Hierarchy SONET Synchronous Optical NETwork SPF Shortest Path First STM-x Synchronous Transport Module level x TCL Tool Command Langage TCP Transport Control Protocol TDP Tag Distribution Protocol TE Traffic Engineering TR Temps Réel (acronyme propre à ce rapport) TTL Timt to live UDP User Datagram Protocol VCI Virtual Channel Identifier VoIP Voice over IP VPI Virtual Path Identifier VPN Virtual Private Network WAN Wide Area Network WFQ Weighted Fair Queuing

Page 10: Mpls foudhaili oussama

Introduction générale

- 1 -

Introduction Générale

La toile Internet connaît actuellement un développement vertigineux. Ce qui a fait de

IP un protocole presque universel. Le succès de ce dernier repose sur sa grande simplicité

puisqu'il se base sur le modèle Best Effort. Toutefois, ce même point qui a fait sa force,

constitue actuellement sa faiblesse. Car le modèle Best Effort a montré ses limites face aux

nouveaux besoins des applications, puisque la demande s'est diversifiée (data, voix, vidéo,

etc.) et les services sont de plus en plus gourmands en ressources. Les nouvelles applications

exigent aujourd'hui de complexifier les réseaux et de prendre en compte les spécifications

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 réseaux télécom.

La réponse à la question de QoS a été pour longtemps ATM. Car l'aspect non connecté

de IP rend difficile d'envisager de lui intégrer des services temps réel.

D'un autre côté, les réseaux IP ont pris une ampleur tellement grande qu'on ne peut

plus envisager de créer une architecture nouvelle répondant aux besoins de QoS. Et même

l'association IP/ATM a montré ses limites. La solution est alors de définir des mécanismes

complémentaires au fonctionnement de IP de base, permettant de prendre en compte les

exigences propres de chaque type de service. Ceci quitte à introduire une complexité

supplémentaire au fonctionnement de IP.

C'est là que MPLS s'est imposé comme une solution leader. MPLS a réussi à

conjuguer la simplicité de IP avec l'efficacité d'ATM dans la gestion du multiservice.

MPLS fait également partie d’un mouvement d’ensemble vers les NGN (Next

Generation Networks) dont le but est de réaliser la convergence voix/données dans une

perspective générale de "tout IP" (EoIP : Everything over IP).

MPLS constitue aussi une alternative à la commutation de circuit, encore largement

utilisée en téléphonie. Ce type de commutation présente l'inconvénient de générer un

gaspillage évident de ressources, puisque c'est une technique à ressources dédiées. MPLS

remédie à ce problème en mettant en œuvre des mécanismes permettant de faire passer du

trafic haute exigence, tel que la voix, dans un réseau à ressources partagées, sans pour autant

Page 11: Mpls foudhaili oussama

Introduction générale

- 2 -

dégrader sa qualité. On peut ainsi passer outre la technique de commutation de circuit et

utiliser la commutation de paquet/label. Le réseau sera alors utilisé d'une façon plus optimale,

ce qui constitue un gain économique pour les opérateurs et les fournisseurs de services.

De plus, avoir à gérer un seul réseau est très important pour un opérateur vu que ça lui

permet de réduire ses coûts. D'autant plus que migrer vers les réseaux MPLS n'est pas très

coûteux puisqu'il existe des solutions qui n'exigent pas de changer tous les équipements : on

peut juste patcher les routeurs déjà installés.

Dans ce rapport, on va s'intéresser à l'étude de MPLS et en particulier à l'application

"Traffic Engineering (TE)". Les chapitres I et II seront consacrés à une vue théorique de ces

deux concepts. Ensuite, on décrira, dans le chapitre III, l'implémentation et les simulations qui

ont permis d'analyser les performances de MPLS TE sur les réseaux multiservice. Pour enfin

essayer d'évaluer l'apport du Trafic Engineering sur le backbone national de Tunisie Télécom.

Page 12: Mpls foudhaili oussama

Chapitre I : MultiProtocol Label Switching

- 3 -

Chapitre I : MultiProtocol Label Switching

(MPLS)

Introduction Précisons dès à présent que MPLS est davantage une architecture qu'un protocole ou

un modèle de gestion. Ainsi, l'architecture MPLS est composée d'un certain nombre de

protocoles et de mécanismes définis, ou en cours de définition.

Nous allons, le long de ce premier chapitre, faire le tour de la technologie MPLS.

Nous commencerons par expliquer son principe de fonctionnement. Nous détaillerons ensuite

les concepts relatifs aux labels et à leurs distributions. Nous finirons par donner un aperçu des

applications que MPLS permet de réaliser.

1 Principe de fonctionnement de MPLS

Figure 1.1 : Exemple d'un réseau MPLS

Un réseau 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.

LSR

LSR

LSR

LSR LSR

LER

LER

LSR

Site 1

Site 2 Domaine MPLS

12.3.2.125

L=18

L=21

L=10921

L=42

L=3 12.3.2.125

Ingress LER

Egress LER

Page 13: Mpls foudhaili oussama

Chapitre I : MultiProtocol Label Switching

- 4 -

• LER (Label Edge Router) : c'est un LSR qui fait l'interface entre un domaine MPLS

et le monde extérieur. En général, 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 gère le trafic qui entre dans un réseau MPLS.

- Egress LER : c'est un routeur qui gère le trafic qui sort d'un réseau MPLS.

Avant d'examiner le fonctionnement d'un réseau MPLS, on va passer en revu le

principe d'acheminement des paquets dans un réseau IP classique et ainsi pouvoir faire une

comparaison des deux techniques.

Dans un réseau IP classique, il y a mise en oeuvre d'un protocole de routage (RIP,

OSPF, IS-IS, etc.) Ce protocole sera exécuté indépendamment par chaque nœud. A la

convergence du protocole de routage, chaque nœud aura une vision plus ou moins complète

du réseau et pourra du coup calculer une table de routage contenant l'ensemble des

destinations. Chaque destination sera associée à un "prochain saut" ou "Next Hop".

Voyant maintenant le cas d'un réseau MPLS : La mise en œuvre de MPLS repose sur

la détermination de caractéristiques communes à un ensemble de paquets et dont dépendra

l'acheminement de ces derniers. Cette notion de caractéristiques communes est appelée

Forwarding Equivalence Class (FEC). Une FEC est la représentation d’un ensemble de

paquets qui partagent les mêmes caractéristiques pour leur transport.

- Le routage IP classique distingue les paquets en se basant seulement sur les adresses

des réseaux de destination (préfixe d’adresse).

- MPLS constitue les FEC selon de nombreux critères : adresse destination, adresse

source, application, QoS, etc.

Quand un paquet IP arrive à un ingress LER, il sera associé à une FEC. Puis, exactement

comme dans le cas d'un routage IP classique, un protocole de routage sera mis en œuvre pour

découvrir un chemin jusqu'à l'egress LER (Voir Figure 1.1, les flèches rouges). Mais à la

différence d'un routage IP classique cette opération ne se réalise qu'une seule fois. Ensuite,

tous les paquets appartenant à la même FEC seront acheminés suivant ce chemin qu'on

appellera Label Switched Path (LSP). Ainsi on a eu la séparation entre fonction de routage et

fonction de commutation : Le routage se fait uniquement à la première étape. Ensuite tous les

Page 14: Mpls foudhaili oussama

Chapitre I : MultiProtocol Label Switching

- 5 -

paquets appartenant à la même FEC subiront une commutation simple à travers ce chemin

découvert.

Pour que les LSR puissent commuter correctement les paquets, le Ingress LER affecte une

étiquette (appelée aussi Label) à ces paquets (label imposition ou label pushing). Ainsi, si 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 opération de

commutation sera exécuter 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 façon 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'après la découverte 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 exécuter la commutation de

label adéquate à chaque paquet entrant. Cette tâche est effectuée 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 opérations fondamentales sur les labels (Pushing, swapping et popping) sont

tout ce qui est nécessaire pour MPLS. Le Label pushing/popping peuvent être le résultat d'une

classification en FEC aussi complexe qu'on veut. Ainsi on aura placé toute la complexité aux

extrémités du réseau MPLS alors que le cœur du réseau exécutera 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 différentes technologies. Ainsi,

MPLS fonctionne indépendamment 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".

Page 15: Mpls foudhaili oussama

Chapitre I : MultiProtocol Label Switching

- 6 -

Ethernet En-tête Ethernet Shim MPLS En-tête couche 3

Frame Relay En-tête FR Shim MPLS En-tête couche 3

ATM GFC VPI VCI PTI CLP HEC DATA

Label

Figure 1.2 : l'encapsulation MPLS dans différentes technologies

Dans le cas ATM, MPLS utilise les champs VPI (Virtual Path Identifier) et VCI

(Virtual Channel Identifier) comme étant un label MPLS.

Dans les autres cas, MPLS insère un en-tête (32 bits) entre la couche 2 et la couche 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 S TTL

Figure 1.3 : Format du shim MPLS

LABEL (20 bits) : Contient le label.

EXP (3 bits) : Initialement réservé pour une utilisation expérimentale. Actuellement, la plus

part des implémentations utilise ce champ comme indicateur de QoS. Généralement, c'est une

copie du champ PRECEDENCE (PPP) dans l'en-tête IP. En IP, la précédence définit la

priorité d'un paquet (0 : priorité supérieure, 7 : priorité inférieure).

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) : Même signification que pour IP. Ce champ donne la limite supérieure au

nombre de routeurs qu'un paquet peut traverser. Il limite la durée de vie du paquet. Il est

initialisé à une certaine valeur, puis décrémenté de un par chaque routeur qui traite le paquet.

En-tête PPP Shim MPLS En-tête couche 3 PPP (Packet over SONET/SDH)

Page 16: Mpls foudhaili oussama

Chapitre I : MultiProtocol Label Switching

- 7 -

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 déjà é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 traversée du réseau MPLS.

Dans le cas de deux niveaux de label, on pourra relier deux réseaux d'un réseau privé au

travers d'un réseau opérateur (Voir figure 1.4), en utilisant un niveau de labels au niveau

opérateur, et un niveau de labels au niveau du réseau privé. Les LSR de frontière de réseau

auront donc la responsabilité de pousser (ou tirer) la pile de labels pour désigner le niveau

d'utilisation courant de label.

Figure 1.4 : Pile de labels

Site 1

10.2.0.174

10.2.0.174

3

9

2

4 2

8 2

7 2

6 2

9 2

6

1

Site 2

Domaine MPLS Opérateur

Page 17: Mpls foudhaili oussama

Chapitre I : MultiProtocol Label Switching

- 8 -

L'utilisation de plusieurs niveaux de labels permet, lors d'interconnexions de disposer

de plusieurs niveaux d'opérateurs. Chacun manipule les labels correspondant à son niveau [1].

4 Concepts relatifs à la distribution de labels Pour comprendre comment les LSR génèrent et distribuent les labels, on doit aborder

quelques concepts relatifs à la distribution de labels [1].

4.1 Contrôle de distribution des labels

Il existe deux modes de contrôle de distribution des labels aux LSR voisins :

• Mode de contrôle ordonné (Ordered control mode) :

Dans ce mode, un LSR associe un label à une FEC particulière, si :

ü Il s'agit d'un Egress LER ;

ü L'assignation (l'association Label, FEC) a été reçue du LSR situé au saut suivant.

• Mode de contrôle indépendant (Independent control mode) :

Dans ce mode, les LSR sont libres de communiquer les associations entre label et FEC

à leurs voisins sans attendre de recevoir l'assignation du LSR situé au saut suivant.

Ainsi, un LSR peut diffuser un label pour une FEC, quand bien même il n'est pas prêt

à communiquer sur ce label.

4.2 Distribution et gestion des labels

La distribution elle-même des labels peut se faire suivant plusieurs méthodes :

• Descente systématique (unsolicited downstream) :

Le LSR en aval envoie le label au LSR précédent (en amont) de manière systématique

(sans demande explicite).

Ainsi dans 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 même destination.

Figure 1.5 : Unsolicited downsteam

LSR A LSR B LSR C

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

Page 18: Mpls foudhaili oussama

Chapitre I : MultiProtocol Label Switching

- 9 -

• Descente à la demande (Downstream-on-Demand) :

Dans ce mode, le LSR en aval envoie le label au LSR précèdent uniquement s'il a reçu

une requête. Et ceci même s'il a déjà généré un label pour la FEC en question.

Figure 1.6 : Downsteam-on-demand

4.3 Conservation des labels

Il existe deux modes que les LSR utilisent pour la conservation des labels reçus :

• Mode de conservation libéral (Liberal retention) :

Dans ce mode, les LSR conservent les labels reçus de tous leurs voisins. Il permet une

convergence plus rapide face aux modifications topologiques du réseau et la

commutation de trafic vers d'autres LSP en cas de changement. En contre partie, ce

mode nécessite beaucoup de mémoire.

• Mode de conservation conservateur (Conservative retention) :

Dans ce mode, les LSR retiennent uniquement les labels des voisins situés sur le saut

suivant et ignorent tous les autres. Ce mode nécessite peu de mémoire. En contre

partie, on aura une adaptation plus lente en cas d'erreur

4.4 Espace de labels (Label Space)

Les labels utilisés par un LSR pour l'assignation de labels à un FEC sont définis de deux

façons :

• Par plate-forme (per-platform label space ou global space) :

Dans ce cas, les valeurs de labels sont uniques dans tous les équipements LSR. Les

labels sont alloués depuis un ensemble commun de labels : de la sorte, deux labels

situés sur des interfaces distinctes possèdent des valeurs distinctes.

LSR A LSR B LSR C

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

Demande de label pour la destination 182.65.10/24

Demande de label pour la destination 182.65.10/24

Page 19: Mpls foudhaili oussama

Chapitre I : MultiProtocol Label Switching

- 10 -

• Par interface (per-interface label space) :

Les domaines de valeurs des labels sont associés à une interface. Plusieurs peuvent

être définis. Dans ce cas, les valeurs de labels fournies sur des interfaces différentes

peuvent être identiques.

Il est clairement stipulé 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 possédant le même label,

mais issus d'interfaces différentes.

4.5 Création des labels

Plusieurs méthodes sont utilisées pour la création des labels, en fonction des objectifs

recherchés.

• Fondée sur la topologie (Topology-based) :

Cette méthode engendre la création de labels à l’issue de l’exécution normale des

processus de routages (comme OSPF ou BGP).

• Fondée sur les requêtes (Request-based) :

Cette méthode de création de labels est déclenchée lors de l’exécution d’une requête

de signalisation.

• Fondée sur le trafic (Traffic-based) :

Cette méthode de création de labels attend la réception d’un paquet de donnée pour

déclancher l’assignation et la distribution de labels. Le protocole IP-Switching de la

société Ipsilon illustre cette méthode.

La dernière méthode est un exemple de protocole fondé sur le modèle orienté données

(data-driven). Ce modèle n'a pas été retenu par MPLS. Dans ce cas, l'assignation de labels

n'est déclenchée qu'à la réception effective de paquets de données et non a priori comme en

mode control-driven. Cette méthode présente l'avantage de justifier le processus de création

de labels et de leur distribution qui se fait uniquement en présence effective d'un trafic

utilisateur. En revanche, elle a l'inconvénient d'obliger l'ensemble des routeurs du réseau à

fonctionner au départ 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

délai entre la reconnaissance d'un flux sur le réseau et la création d'un label pour ce flux.

Page 20: Mpls foudhaili oussama

Chapitre I : MultiProtocol Label Switching

- 11 -

Enfin, en présence d'un nombre important de flux de trafic (sur un grand réseau), le processus

de distribution de labels peut devenir complexe et lourd à gérer.

Les deux premières méthodes exposées sont des exemples d'assignation de labels

établis à partir du modèle orienté contrôle (control-driven), à savoir qu'à l'inverse du modèle

précédent, les labels sont assignés et distribués préalablement à l'arrivée des données de trafic

de l'utilisateur. C'est le modèle retenu et utilisé par MPLS.

Voici les principaux protocoles de distribution de labels envisagés :

• TDP (Tag Distribution Protocol) : Prédécesseur de LDP.

• LDP (Label Distribution Protocol) : Protocole créé spécifiquement.

• BGP (Border Gateway Protocol) : Amélioration de BGP pour la distribution des

labels

• PIM (Protocol Independent Multicast) : Amélioration de PIM pour la distribution des

labels

• CR-LDP (Constraint-based Routing LDP) : Amélioration de LDP

• RSVP TE (Ressource ReSerVation Protocol Traffic Engineering) : Amélioration de

RSVP

Les quatre premières approches sont fondées sur la topologie (Topology-based). Les deux

dernières approches sont fondées sur les requêtes (Request-based). Et ce sont ces deux

protocoles de distribution de labels qui sont utilisés pour le MPLS Traffic Engineering. On va

les revoir plus en détail 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 présente quelques protocoles de distribution de labels et

leurs modes de fonctionnements respectifs :

Page 21: Mpls foudhaili oussama

Chapitre I : MultiProtocol Label Switching

- 12 -

Protocole de

distribution

de label

Contrôle Distribution Conservation Espace de

label Création

TDP et LDP Unordered Downstream

unsolicited Liberal Per platform

Topology-

based

TDP et LDP

(avec ATM) Ordered

Downstream on

Demand Conservative Per interface

Topology-

based

RSVP TE Ordered Downstream on

Demand Conservative Per platform

Request-

based

CR-LDP Unordered/

Ordered

Downstream unsolicited/

Downstream on Demand

Liberal/

Conservative

Per platform/

Per interface

Request-

based

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

5 Les applications de MPLS La motivation primaire de MPLS était d'accroître la vitesse de traitement des paquets

au niveau des nœuds intermédiaires. Cela dit, aujourd'hui MPLS offre peu sinon pas

d'amélioration du tout dans ce sens : les routeurs actuels sont équipés avec des circuits et des

algorithmes permettant un acheminement (forwarding) des paquets extrêmement rapide.

Donc, traiter des paquets sur la base de label de 20 bits de MPLS n'est plus significativement

rapide par rapport à traiter des paquets sur la base d'adresse de 32 bits de IP.

Aujourd'hui, les motivations réelles pour déployer des solutions MPLS sont les

applications que MPLS permet et qui étaient très difficiles voire impossibles à mettre en

œuvre avec IP traditionnel. Ces applications sont très importantes pour les opérateurs et les

ISP (Internet Service Provider), tout simplement parce qu'elles peuvent être vendues

Il existe aujourd'hui quatre applications majeures de MPLS. Ces applications

supposent la mise en œuvre de composants adaptés aux fonctionnalités recherchées.

L'implémentation de MPLS sera donc différente en fonction des objectifs recherchés. Cela se

traduit principalement par une façon différente 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 mécanisme de base commun à toutes les approches.

Page 22: Mpls foudhaili oussama

Chapitre I : MultiProtocol Label Switching

- 13 -

Les principales applications de MPLS concernent :

• Any Transport over MPLS (AToM) ;

• Le support des réseaux privés virtuels (MPLS VPN, Virtual Private Network) ;

• Le support de la qualité de service (MPLS QoS) ;

• Le Traffic Engineering (MPLS TE).

5.1 Any Transport over MPLS (AToM)

Ce service traduit l'indépendance de MPLS vis-à-vis des protocoles de couches 2 et 3.

AToM est une application qui facilite le transport du trafic de couche 2, tel que Frame Relay,

Ethernet, PPP et ATM, à travers un nuage MPLS [3].

5.2 Le support des réseaux privés virtuels (MPLS VPN) Un réseau privé virtuel (VPN) simule le fonctionnement d'un réseau étendu (WAN) privé

sur un réseau public comme Internet. Afin d'offrir un service VPN fiable à ses clients, un

opérateur ou un ISP doit alors résoudre deux problématiques essentielles :

• Assurer la confidentialité des données transportées ;

• Prendre en charge des plans d'adressage privé, fréquemment identiques.

La construction de VPN repose alors sur les fonctionnalités suivantes :

• Systèmes de pare-feu (Firewall) pour protéger chaque site client et permettre une

interface sécurisée avec Internet ;

• Système d'authentification pour vérifier que chaque site client échange des

informations avec un site distant valide ;

• Système de cryptage pour empêcher l'examen ou la manipulation des données lors du

transport sur Internet ;

• Tunneling pour permettre un service de transport multiprotocole et l'utilisation de

plans d'adressage privés

MPLS permet de résoudre efficacement la fonctionnalité de tunneling, dans la mesure où

l'acheminement des paquets n'est pas réalisé 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

déployant un ensemble de LSP pour permettre la connectivité entre différents sites du VPN

Page 23: Mpls foudhaili oussama

Chapitre I : MultiProtocol Label Switching

- 14 -

d'un client donné. Chaque site du VPN indique à l'ISP l'ensemble des préfixes (adresses)

joignables sur le site local. Le système de routage de l'ISP communique alors cette

information vers les autres sites distants du même VPN, à l'aide du protocole de distribution

de labels. En effet, l'utilisation d'identifiant de VPN permet à un même système 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é.

Figure 1.7 : MPLS VPN

Il existe une autre approche permettant de mettre en œuvre des VPN sur les réseau IP :

IPSec. IPSec privilégie la sécurisation des flux d'information par encryptage des données,

alors que MPLS se concentre plutôt sur la gestion de la qualité de service et la priorité des

flux.

Le problème de sécurité dans MPLS VPN est minimal dans le cas où le réseau est

propriétaire (non Internet). Cependant, si cette garantie n'est pas suffisante, il existe des

solutions qui permettent d'utiliser en même temps MPLS et IPSec [2] et ainsi construire des

VPN disposant des avantages des deux approches en même temps : la souplesse de MPLS et

la sécurisation de IPSec.

VPN 1

VPN 1

VPN 2

VPN 2

VPN 1

VPN 2

LER

LER

LER

LER

LER

LER

Page 24: Mpls foudhaili oussama

Chapitre I : MultiProtocol Label Switching

- 15 -

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

Le support de la QoS peut être mise en œuvre de deux façons sur MPLS [1] :

• Les trafics sur un même LSP peuvent se voir affecter à différentes files d'attente dans

les routeurs LSR, selon la valeur du champ EXP de l'en-tête MPLS (Voir Figure 1.3).

Le principe du champ EXP dans MPLS est le même que le champ Precedence (PPP)

dans IP (Voir plus haut le détail de ce champ).

• 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

résultat immédiat est l'amélioration de paramètres tel que le délai ou la gigue dans le réseau.

Elle est tout de même considérée comme une application à part entière par la plupart des

industriels. Ceci vient du fait que MPLS TE n'est pas une simple technique de réservation de

ressources pour les applications réseau. C'est un concept plus global qui se veut être une

solution qui vise à augmenter les performances générales du réseau en jouant sur la répartition

équilibrée des charges (trafics) dans le réseau pour ainsi avoir une utilisation plus optimale

des liens.

Le Traffic Engineering va être repris d'une façon théorique dans le chapitre II, puis à

travers les simulations dans les chapitres III et IV.

Conclusion Même si le temps de routage n’est plus l’intérêt de cette technologie, MPLS est

toujours très favorable pour s'imposer dans le monde des réseaux.

Les offres MPLS au niveau de la qualité de service, de VPN ou de Traffic Engineering

assureront à ce protocole un succès tant au près des utilisateurs que des opérateurs et

fournisseurs de services. Son succès vient également du fait qu’il 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.

Page 25: Mpls foudhaili oussama

Chapitre II : MPLS Traffic Engineering

- 16 -

Chapitre II : MPLS Traffic Engineering

(MPLS TE)

Introduction Dans ce chapitre, on va commencer par expliquer la notion de Traffic Engineering et

les améliorations qu'il permet d'apporter à l'utilisation du réseau. Ensuite, on va aborder les

mécanismes et protocoles qui permettent de mettre en œuvre des solutions MPLS TE dans un

réseau.

1 Les motivations du Traffic Engineering

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 critère

du plus court chemin [3]. Et puisque tous les liens ont le même coût (15), les paquets venant

de R1 ou R7 est qui sont destinés à R6 vont tous suivre le même chemin (R2 à R5 à R6).

R1

R2

R3

R5 R6

R4

R7

Coût : 15

Coût : 15

Coût : 15

Coût : 15

Coût : 15

Coût : 15

Coût : 15

Le chemin le plus court

Page 26: Mpls foudhaili oussama

Chapitre II : MPLS Traffic Engineering

- 17 -

Ceci peut conduire à quelques problèmes : supposant que tous les liens de la figure 2.1

supportent une bande passante de 150Mbps. Et supposant que R1 envoie en moyenne 90Mbps

à 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 procédure de

routage fera que ce trafic utilisera aussi le chemin le plus court. En final, on aura deux trafics

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

réseau vu que réellement, il existe un chemin dans le réseau qui n'est pas exploité et que son

utilisation aurait permis de satisfaire les deux trafics.

Comment peut on alors résoudre ce problème? Avec IP classique on pourra faire de

sorte que les deux chemins aient le même coût. Cependant cette solution marche seulement

avec des réseaux 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 réseaux ATM permettent aussi de réaliser une telle ingénierie des flux. Le

problème c'est qu'ils introduisent en parallèle une grande complexité de gestion : en effet IP et

ATM sont deux techniques réseaux totalement différentes, avec parfois des contraintes non

compatibles.

Contrairement aux solutions IP et ATM, MPLS va permettre une simplification

radicale de l'intégration de cette fonctionnalité dans les réseaux.

MPLS TE permet à l'ingress LER de contrôler le chemin que son trafic va emprunter

pour atteindre une destination particulière. Ce concept est connu sous le nom de "Explicit

Routing". Cette méthode est plus flexible que l'acheminement du trafic basé seulement sur

l'adresse destination. MPLS TE réserve 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

Page 27: Mpls foudhaili oussama

Chapitre II : MPLS Traffic Engineering

- 18 -

Les LSP ainsi construits sont appelés MPLS TE LSP ou TE tunnels. On s'approfondira

dans les mécanismes de création des MPLS TE LSP dans le paragraphe 2.

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

réseau (le contournement de la congestion) ;

• Le contrôle précis 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 réseau, 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'améliorer statistiquement les paramètres de QoS

(Taux de perte, délai, gigue, etc.)

Un exemple concret de Traffic Engineering est qu'il est possible de définir plusieurs

LSP entre chaque couple de LER. Chaque LSP peut être conçu (grâce aux techniques de

Traffic Engineering) pour fournir différentes garanties de bande passante ou de performances.

R1

LSR2

LSR3

LSR5 LSR6

LSR4

R7

Coût : 15

Coût : 15

Coût : 15

Coût : 15

Coût : 15

Coût : 15

Coût : 15

Tunnel1

Tunnel2

Page 28: Mpls foudhaili oussama

Chapitre II : MPLS Traffic Engineering

- 19 -

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 troisième LSP.

2 Calcul et établissement des "MPLS TE LSP" Dans un protocole de routage à état de lien (tel que OSPF ou IS-IS), chaque routeur

connaît tous les routeurs du réseau et les liens qui connectent ces routeurs.

Aussi tôt qu'un routeur se fait une idée de la topologie du réseau, il exécute le "Dijkstra

Shortest Path First algorithm" (SPF) pour déterminer le plus court chemin entre lui-même et

tous les autres routeurs du réseau (Construction de la table de routage). Etant donné que tous

les routeurs exécutent le même calcul sur les mêmes données, chaque routeur aura la même

image du réseau, et les paquets seront routés de manière cohérente à chaque saut.

Le processus qui génère un chemin pour un "MPLS TE LSP" est différent du SPF

classique, mais pas trop. Il y a deux différences majeures entre le SPF classique, utilisée par

les protocoles de routage, et le CSPF (Constrained Shortest Path First), utilisé par MPLS TE :

• Le processus de détermination de chemin n'est pas conçu pour trouver le plus court

chemin, mais il tient compte d'autres contraintes ;

• Il y a plus d'une métrique à chaque nœud, 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 par CSPF pour calculer un

MPTS TE LSP. Il peut manuellement imposer un chemin explicite à une FEC donnée. Dans

certaines littératures, on appelle les TE LSP calculés par des algorithmes basés sur la situation

du trafic des CR-LSP (Constraint-based Routing - LSP), et les TE LSP spécifiés

explicitement par l'administrateur des ER-LSR (Explicit Routing - LSP).

MPLS crée les LSP différemment selon qu'on utilise le Traffic Engineering ou non.

La création 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).

Page 29: Mpls foudhaili oussama

Chapitre II : MPLS Traffic Engineering

- 20 -

La création d'un "MPLS TE LSP" suit les deux étapes suivantes :

• Calcul du "MPLS TE LSP" : Mise en œuvre de l’algorithme 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).

Après avoir calculer un chemin avec CSPF, ce chemin doit être signalé à travers le réseau, et

ceci pour deux raisons :

• Etablir une chaîne de labels qui représente le chemin ;

• Réserver les ressources nécessaires (bande passante) à travers le chemin.

Dans ce qui suit, on va détailler l'étape de l'établissement du "MPLS TE LSP" en

examinant de prés le fonctionnement des protocoles de distribution de labels RSVP TE et CR-

LDP. On va se concentrer plus sur RSVP TE vu que l'étude pratique porte sur ce protocole.

3 Resource ReSerVation Protocol - Traffic Engineering

(RSVP TE) Ce protocole [3] est originalement destiné à être un protocole de signalisation pour

IntServ (C'est un modèle de QoS où une machine demande du réseau une QoS donnée pour

un flux donné). RSVP avec quelques extensions a été adapté par MPLS pour être un protocole

de signalisation qui supporte MPLS TE.

Nous allons, dans cette partie, commencer par illustrer le format général des messages

RSVP TE. Pour enfin expliquer avec plus ou moins de détails le fonctionnement de ce

protocole.

Page 30: Mpls foudhaili oussama

Chapitre II : MPLS Traffic Engineering

- 21 -

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 résumés dans le tableau 2.1.

Type de message Description

Path Utilisé pour l'établissement et le maintien des chemins

Resv Envoyé en réponse au message Path

PathTear Analogue au message Path, mais utilisé pour supprimer les

réservations du réseau

ResvTear Analogue au message Resv, mais utilisé pour supprimer les

réservations du réseau

PathErr Envoyé par un récepteur d'un message Path qui détecte une erreur

dans ce message

ResvErr Envoyé par un récepteur d'un message Resv qui détecte une

erreur dans ce message

ResvConf Optionnellement envoyé à l'émetteur d'un message Resv pour

confirmer qu'une réservation donnée est bien établie

ResvTearConf

Analogue à ResvConf. Optionnellement envoyé à l'émetteur d'un

message ResvTear pour confirmer qu'une réservation donnée est

supprimée

Hello Envoyé entre voisins directement connectés

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-tête commun (commun Header) et d'un

nombre variable d'objets selon le type de message (voir figure 2.4).

En-tête MAC En-tête IP Message RSVP TE

Figure 2.3 : L'encapsulation des messages RSVP TE

Page 31: Mpls foudhaili oussama

Chapitre II : MPLS Traffic Engineering

- 22 -

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Version Flags Message type RSVP checksum

Send TTL Reserved RSVP length

Objects

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 définit.

Message Type (8 bits) :

1 = Path message

2 = Resv message

3 = PathErr message

4 = ResvErr message

5 = PathTear message

6 = ResvTear message

7 = ResvConf message

10 = ResvTearConf message

20 = Hello message

RSVP Checksum (16 bits) : Utilisé pour la détection d'erreur. Même 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 supérieure à 8.

3.1.3 Le format des objets RSVP TE

Chaque message RSVP TE peut contenir plusieurs objets. Le format général 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 C-type Object contents

Figure 2.5 : Format des objets RSVP TE

Common Header

Page 32: Mpls foudhaili oussama

Chapitre II : MPLS Traffic Engineering

- 23 -

Object Length (16 bits) : La longueur de l'objet RSVP en octet, en-tête de l'objet inclus. La

valeur de ce champ est donc toujours supérieure à 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-même.

Chaque classe a son propre espace de numéro C-Type. Par exemple, la classe

SESSION a 4 C-Types : IPv4, IPv6, LSP_TUNNEL_IPv4, et LSP_TUNNEL_IPv6. Les

numéros assignés à 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 numéros

assignés à ces C-Types sont 1, 2, et 3. Ainsi pour identifier le contenu d'un message, on doit

prendre en compte les numéros de classe et le numéro de C-Type. On peut voir les classes et

C-Types comme une sorte du numérotation hiérarchique.

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]

SENDER_TEMPLATE

SENDER_TSPEC

[ADSPEC]

[RECORD_ROUTE]

Figure 2.6 : Format du Path message

Common Header

[INTEGRITY]

SESSION

NHOP

TIME_VALUES

[RESV_CONFIRM]

[SCOPE]

[POLICY_DATA]

STYLE

FLOWSPEC

FILTER_SPEC

LABEL

[RECORD_ROUTE]

Figure 2.7 : Format du Resv message

Objets

Page 33: Mpls foudhaili oussama

Chapitre II : MPLS Traffic Engineering

- 24 -

Chacun des objets contenus dans un message RSVP TE rempli une fonction de

signalisation particulière. Des exemples seront donnés dans le paragraphe suivant.

3.2 Le fonctionnement de RSVP TE

RSVP TE est un mécanisme de signalisation utilisé pour réserver des ressources à

travers un réseau. RSVP TE n'est pas un protocole de routage. Toute décision de routage est

faite par IGP (Interior Gateway Protocol). Le seul travail de RSVP TE est de signaler et de

maintenir la réservation de ressources à travers le réseau.

RSVP TE a trois fonctions de base :

• L'établissement et la maintenance des chemins (Path setup and maintenance)

• La suppression des chemins (Path teardown)

• La signalisation des erreurs (Error signalling)

RSVP TE est un "soft-state protocol". Cela veut dire qu'il a besoin de rafraîchir

périodiquement ses réservations dans le réseau. Ceci est différent des "hard-state protocol",

qui signalent leurs requêtes une seule fois et puis supposent qu'elle reste maintenue jusqu'à sa

résiliation explicite. Avec RSVP TE, une requête est résiliée si elle l'est explicitement du

réseau par RSVP TE ou si la durée de réservation expire.

3.2.1 L'établissement et la maintenance des chemins

Bien que l'établissement et la maintenance des chemins soient des concepts très

proches et utilisent les mêmes formats de messages, toutefois, ils différent légèrement. C'est

pourquoi, on va les expliquer séparément.

• L'établissement des chemins

Après que l'ingress LER (appelé aussi MPLS TE tunnel headend ou headend) ait

terminé sa procédure CSPF pour un tunnel particulier, il doit signaler le chemin trouvé à

travers le réseau. Le headend réalise cette opération en envoyant un Path message au 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 séquence de nœuds. Le headend ajoute un objet LABEL_REQUEST

qui indique qu'une association de label est requise pour ce chemin et quel type de protocole

Page 34: Mpls foudhaili oussama

Chapitre II : MPLS Traffic Engineering

- 25 -

réseau sera véhiculé 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 spécifiée dans l'objet EXPLICIT_ROUTE. Au fur est à

mesure de l'avancement du Path message, chaque LSR intermédiaire effectue les deux actions

suivantes :

• Il vérifie le format du message pour s'assurer qu'il n'est pas corrompu

• Il vérifie la quantité de bande passante que le Path message reçu demande en utilisant

les informations contenues dans les objets SESSION_ATTRIBUTE, SENDER_TSPEC

et POLICY_DATA. Ce processus est appelé "contrôle d'admission".

Si le contrôle d'admission réussit et le Path message est autorisé à réserver la bande passante

qu'il demande, le LSR intermédiaire crée un nouveau Path message et l'envoie au "next hop"

(en se référant à l'objet EXPLICIT_ROUTE).

Les Path messages refont cette procédure avec tous les routeurs du chemin à établir

jusqu'à atteindre le dernier nœud dans l'EXPICITE_ROUTE. Le tunnel tail réalise le contrôle

d'admission en le Path message, exactement comme n'importe quel nœud intermédiaire.

Quand le tail réalise qu'il est la destination du Path message, il répond par un Resv message.

On peut considérer le Resv message comme un acquittement (ACK) pour le saut précédent

(Previous Hop, PHOP).

Le Resv message n'est pas qu'un acquittement témoignant de la réussite de la réservation,

mais il contient aussi le incoming label que le Previous Hop doit utiliser pour l'envoie de

paquets de données le long du TE LSP jusqu'au tail. En effet, L'objet LABEL_REQUEST

(Path message) réclame aux LSR traversés et au tail une association de label pour la session.

Le tail répond au LABEL_REQUEST en incluant un objet LABEL dans son message de

réponse RESV. Puis le RESV message est renvoyé vers le headend, en suivant le chemin

inverse à celui spécifié dans l'objet EXPLICIT_ROUTE. Chaque LSR qui reçoit le message

RESV contenant l'objet LABEL utilisera ce label pour le trafic de donnée 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 (grâce à l'information PHOP qu'il aura

mémorisée 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 création de ce

LSP, des messages de rafraîchissement RSVP TE devront être émis périodiquement afin de

maintenir le LSP créé (soft-state protocol).

Page 35: Mpls foudhaili oussama

Chapitre II : MPLS Traffic Engineering

- 26 -

Nous allons résumer le processus d'établissement des chemins avec l'exemple de la

figure 2.8 :

Figure 2.8 : Path et Resv messages, lors de l'établissement de chemin

Supposant que R1 a déjà réalisé sa procédure CSPF et a déjà décidé des besoins en bande

passante qu'il veut réserver le long du chemin (R1àR2àR3àR5àR6àR7) :

(1) R1 envoie un Path message à R2. R2 reçoit le Path message, vérifie le format du

message et la disponibilité de la bande passante demandée par R1. S'il y a un

problème, R2 envoie un message d'erreur (PathErr) vers R1. Si tout se passe bien, on

passe à l'étape (2)

(2) R2 envoie un Path message à R3. R3 fait les mêmes vérifications que dans l'étape(1)

(3) R3 envoie un Path message à R5. Réalisation des mêmes vérifications.

(4) R5 envoie un Path message à R6. Réalisation des mêmes vérifications.

(5) R6 envoie un Path message à R7. Réalisation des mêmes vérifications.

(6) R7, étant le tunnel tail, envoie un Resv message à R6. Ce Resv message contient le

label que R7 veut voir dans les paquets de ce tunnel. Puisque R7 est le tail, il envoie

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 R6 reçoit le label 42, il enlève ce

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 R5 reçoit un paquet de donnée

avec le label 10921, il le change (swapping) en 42 et envoie le paquet vers R6.

R1

R2

R3

R4

R6

R5

R7

R8

L=18

L=21

L=10921

L=42

L=implicit -null (1)

(2)

(3)

(4)

(5)

(6)

(7)

(8)

(9)

(10)

RESV

PATH

Page 36: Mpls foudhaili oussama

Chapitre II : MPLS Traffic Engineering

- 27 -

(9) R3 envoie un Resv message à R2, en signalant le label 21

(10)R2 envoie un Resv message à R1, en signalant le label 18 ;

A ce stade, Le TE LSP est complètement établie entre R1 et R7. Le headend (R1) peut alors

commencer à envoyer les données.

• La maintenance des chemins

D'un premier coup d'œil, la maintenance des chemins et très 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 reçoit pas de Resv

message correspondant, il considère la réservation supprimée et envoie un message dans le

sens inverse indiquant que la réservation est supprimée.

Cependant, il y a une chose importante à comprendre ici. Path et Resv messages sont tous les

deux envoyés d'une façon indépendante et asynchrone d'un voisin à un autre. Si on regarde

encore une fois la figure 2.8, chaque 30 secondes, R1 envoie un Path message à R2 pour la

réservation qu'il a effectué. Et chaque 30 secondes, R2 envoie un Resv message à R1 pour la

même réservation. Cependant, les deux messages ne sont pas connectés. Un Resv message

utilisé pour rafraîchir une réservation existante n'est pas envoyé en réponse à un Path

message, comme c'est le cas de ICMP Echo Reply qui est envoyé en réponse à 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 procédure assez simple. Si un nœud décide qu'une

réservation n'est plus nécessaire dans un réseau, il envoie un PathTear le long du même

chemin que le Path message a suivi et un ResvTear le long du même chemin que le Resv

message a suivi. ResvTear messages sont envoyés en réponse aux PathTear messages pour

signaler que le tunnel tail a supprimé la réservation du réseau.

Exactement comme les messages de rafraîchissement, PathTear messages n'ont pas à

traverser la totalité du chemin avant que leur effet ne prend place. Dans la figure 2.8, si R1

envoie un PathTear à R2, R2 répond immédiatement par un ResvTear et puis envoie son

propre PathTear au next hop.

Page 37: Mpls foudhaili oussama

Chapitre II : MPLS Traffic Engineering

- 28 -

3.2.3 La signalisation des erreurs

De temps en temps, des problèmes peuvent avoir lieu dans le réseau (Bande passante

non disponible, boucle de routage, routeur intermédiaire ne prend pas en charge MPLS,

message corrompu, création de label impossible, etc.). Ces erreurs sont signalées par PathErr

ou ResvErr messages. Une erreur détectée dans un Path message est traitée par un PathErr

message, et une erreur détectée dans un Resv message est traitée par un ResvErr message.

Les messages d'erreurs sont envoyés 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é apportées au protocole LDP pour permettre la

spécification du trafic. Ce protocole a été nommé CR-LDP (Constraint-based Routing over

Label Distribution Protocol) [4]. L'idée de ce protocole était d'utiliser un protocole de

distribution de label déjà existant et de lui ajouter la capacité de gérer le Traffic Engineering.

Sans entrer dans les détails de LDP, CR-LDP ajoute des champs à ceux déjà définis

dans LDP, tel que "peak date rate" et "committed data rate". Le premier indique le débit

maximum avec lequel un trafic peut être envoyer via le TE LSP et le deuxième indique le

débit garanti par le domaine MPLS pour ce trafic. La gestion des réservations dans CR-LDP

est très similaire à celle utilisée dans les réseaux ATM, Alors que RSVP TE utilise plutôt le

modèle de IntServ.

4.1 Les messages CR-LDP

Il y a quatre catégories de message CR-LDP :

• Discovery messages : utilisés pour annoncer et maintenir la présence des LSR dans le

réseau. Ceci est réalisé par l'envoie périodique de messages Hello.

• Session messages : utilisés pour établir, maintenir et libérer des sessions entre des

voisins LDP.

• Advertisement messages : utilisés pour créer, changer et libérer des associations de

FEC et LSP.

Page 38: Mpls foudhaili oussama

Chapitre II : MPLS Traffic Engineering

- 29 -

• Notification messages : utilisés pour véhiculer les informations de supervision.

Il y a deux sortes de Notification messages :

- Error notifications : utilisés pour signaler les erreurs fatales. Quand ces

messages sont reçus, la session LDP est terminée et toutes les associations de

labels correspondantes sont annulées.

- Advisory notifications : utilisés pour véhiculer des informations sur la session

LDP.

4.2 Le fonctionnement de CR-LDP On va expliquer d'une façon concise les étapes qui aboutissent à l'établissement d'un

CR-LDP LSP. Pour cela, examinant la figure 2.9 :

Figure 2.9 : Etablissement d'un CR-LDP LSP

(1) Ingress LSR A détermine 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 détail des paramètres du trafic nécessaire

pour cette nouvelle route.

(2) LSR B reçoit le LABEL_REQUEST message, réserve les ressources demandées,

modifie l'explicit route dans le LABEL_REQUEST message et fait suivre le message à

LSR C. Si nécessaire, LSR B peut réduire les réservations demandées dans le cas où

les paramètres correspondant sont marqués négociables dans le LABEL_REQUEST

message.

(3) LSR C détecte que c'est lui l'egress LSR. Il fait les mêmes activités de réservation et

de négociation que LSR B. Il alloue un label pour le nouveau LSR et l'envoie à LSR

B dans un LABEL_MAPPING message. Ce message contient aussi les détails des

paramètres finaux du trafic pour cet LSP.

LSR A Ingress

LSR B

LABEL REQUEST (B,C)

(1) (2)

(3) (4)

LSR C Egress

LABEL REQUEST (C)

LABEL MAPPING (17) LABEL MAPPING (32)

(5)

Page 39: Mpls foudhaili oussama

Chapitre II : MPLS Traffic Engineering

- 30 -

(4) LSR B reçoit le LABEL_MAPPING message, il finalise la réservation, alloue un label

pour le LSP et met à jour sa table de labels. Ensuite, il envoie le nouveau label à LSR

A dans un autre LABEL_MAPPING message.

(5) Le même processus se réalise dans LSR A. Mais vu que LSR A est l'ingress LSR, il

n'aura pas à allouer un label.

Ainsi le nouveau LSR est établi et les données 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 libération explicite. Ce qui n'est pas le cas RSVP

TE qui doit périodiquement entretenir ses LSP par des messages de signalisation (soft-state

protocol). Cette différence permet à certain de dire que CR-LDP est plus scalable (résistant à

l'augmentation de la taille du réseau), vu que dans le cas de RSVP TE, plus le réseau est

étendue plus il sera encombré par des messages de rafraîchissement. Malgré ceci, RSVP 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 conséquent plus

mature et franc de bugs ; d'autant plus que le constat qu'on a fait sur la scalabilité de ce

protocole est très discutable.

Conclusion Au terme de ce chapitre, nous avons terminé l'étude théorique 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'intérêt et de MPLS et son apport pour un opérateur ou un fournisseur de service en

terme de "Traffic Engineering".

Page 40: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 31 -

Chapitre III : Implémentation et simulation des

fonctionnalités de MPLS TE

Introduction Le but de ce chapitre est de mettre en évidence les fonctionnalités de MPLS TE en

utilisant la simulation comme moyen d'évaluation.

On va commencer par expliciter les paramètres sur lesquels on va se baser dans notre

évaluation, à savoir les paramètres de Qualité de Service. Ensuite, on va présenter

l'environnement de simulation utilisé, pour enfin expliquer la simulation étudiée et procéder à

l’analyse des résultats obtenus.

1 La qualité de service La qualité de service (QoS) [5] décrit le niveau de performance attendu d'une

application, d'un serveur, d'un réseau ou de tout autre dispositif. Par exemple pour une

application, les paramètres principaux à envisager pour évaluer la QoS sont en général la

bande passante, le taux de perte en paquets, le délai de bout en bout et la gigue [6].

1.1 Bande Passante (Bandwidth)

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 réseau est vide. Il en est autrement

s'il existe plusieurs flux qui traversent le réseau. Le calcul de la bande passante est d'autant

plus complexe qu'il y a de considérations à respecter (capacité du lien, nombre de flux et leurs

demandes respectives, priorité, réservation préalable, etc.)

10Mbps 128 kbps 100 Mbps 512 kbps

Terminal A Terminal B

Page 41: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 32 -

1.2 Perte en paquets (Paquet Loss)

Généralement, 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 particulière est

saturée, les nouveaux paquets qui seront dirigés 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 pas traiter le paquet (la

file d'attente d'entrée est saturée) ;

• Le routeur détecte une erreur dans le paquet (Paquet corrompu) ;

• Le routeur rejette les paquets les moins prioritaires en cas de congestion dans le

réseau.

D'autres facteurs peuvent constitués 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 Délai de bout en bout (End to End Delay)

Figure 3.2 : Illustration du concept de délai de bout en bout

Le délai de transmission de bout en bout est le temps écoulé entre l'émission du paquet

et sa réception à l'arrivée. La figure 3.2 illustre l'impacte qu'a le réseau sur le délai de bout en

bout des paquets transmis d'un Terminal A vers un Terminal B. Chaque saut dans le réseau

ajoute un délai supplémentaire dû aux trois facteurs suivant :

• Délai de propagation : C'est le temps que prend la transmission d'un bit via le média

de transmission (paire torsadée, fibre optique, voie radio, etc.)

Délai de propagation

Terminal A Terminal B

Délai de propagation

Délai de propagation

Délai de propagation

Délai de traitement et de mise en file d'attente

Délai de traitement et de mise en file d'attente

Délai de traitement et de mise en file d'attente

Page 42: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 33 -

• Délai de traitement : C'est le temps que consomme un routeur pour prendre un paquet

de l'interface d'entrée et le mettre dans la file d'attente de l'interface de sortie. Ce délai

dépend 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.

• Délai de mise en file d'attente : C'est le temps que le paquet passe dans la file d'attente

de sortie du routeur. Il dépend du nombre et de la taille des paquets déjà dans la file et

de la bande passante de l'interface. Il dépend aussi du mécanisme de file d'attente

adopté.

Le délai de bout en bout est la somme de tous les délais (propagation, traitement et file

d'attente) à travers le chemin parcouru depuis la source jusqu'à la destination. Le délai de

propagation est fixe (ne dépend que du média de transmission), alors que le délai de

traitement et le délai de mise en file d'attente sont variables (dépendent du trafic).

1.4 Gigue (Jitter)

C’est la variation (en ms) du délai entre les paquets consécutifs (Voir Figure 3.3). La

présence de gigue dans les flux peut provenir des changements d'intensité de trafic sur les

liens de sorties des commutateurs. Plus globalement, elle dépend du volume de trafic et du

nombre d'équipements sur le réseau.

La gigue affecte les applications qui transmettent les paquets à un certain débit fixe et

s'attendent à les recevoir au même débit (par exemple : voix et vidéo).

Page 43: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 34 -

Figure 3.3 : Illustration du concept de la gigue

1.5 Les exigences des différentes applications IP en terme de QoS

Les problèmes de qualité de service sont pratiquement inexistants en téléphonie

commutée ; puisque cette dernière utilise la commutation de circuit qui consiste en

l'établissement d'une connexion physique de bout en bout, dédiée à chaque paire d'émetteurs

récepteurs.

Dans le monde IP, La QoS est un passage obligatoire. Car contrairement au réseau

téléphonique commuté, les réseaux IP véhiculent une multitude d'applications qui différent

par leurs exigences en terme de QoS. Ces applications concourent pour se partager une

quantité de ressources limitée offerte par le réseau. C'est pourquoi il est primordial de pouvoir

cerner les besoins nécessaires (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

Sensibilité à la perte en

paquets

Sensibilité au délai

Sensibilité à la gigue

Voix (VoIP) Elevé Moyenne Elevé Elevé

Vidéo (Vidéoconférence) Elevé Moyenne Elevé Elevé

Application interactive (HTTP, jeux en ligne) Moyenne Elevé Moyenne Non

importante

Best effort (FTP) Moyenne Elevé Faible Non importante

Background (mail) Faible Elevé Faible Non importante

Tableau 3.1 : Les exigences des différentes applications IP en terme de QoS

Emission

Réception

Gigue

Page 44: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 35 -

Dans le tableau ci-dessus, il est intéressant de remarquer - à titre d'exemple - que les

applications temps réel (voix, vidéo) sont très sensibles au délai et à la gigue, ce qui n'est pas

le cas des applications orientées donnée. En contre partie, les applications temps réel sont

assez tolérantes aux pertes alors qu'une application comme mail ou FTP ne tolère pas du tout

les pertes.

2 L'environnement de simulation

2.1 L'intérêt d’utiliser un simulateur

Les mécanismes utilisés dans les réseaux IP (protocole de routage, file d'attente et dans

notre cas MPLS) doivent être évalués afin de mesurer les performances des stratégies utilisées

et de tester leur fiabilité. L'utilisation d'un réseau réel dans une évaluation est difficile et

coûteuse, en outre de telles évaluations ne donnent généralement pas des résultats

significatifs. Le réseau réel n'offre pas la souplesse de varier les différents paramètres de

l'environnement et pose en plus le problème d'extraction de résultats ; 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 variété de

conditions.

Pour notre projet, nous avons choisi de travailler avec « Network Simulator 2 (NS2) ».

2.2 Présentation de NS2

NS ou "Network Simulator" [7] est un simulateur de réseau IP, à évènements discrets,

orienté objet. C’est un projet piloté par l’ISI (University of Southern California, USA). Il est

gratuit, open source, portable et mis à jour régulièrement. Il tourne sur plusieurs distributions

d’UNIX et de Windows.

C’est le simulateur le plus utilisé dans la communauté scientifique. Il permet à

l’utilisateur de simuler plusieurs communications entre les différents nœuds d’un réseau. Il est

bien adapté pour simuler la circulation de paquets dans les réseaux commutés. Il est

principalement utilisé pour tester des algorithmes de file d’attente, de contrôle de congestion,

des protocoles de transport, des protocoles de routage, le multicast et la mobilité.

Page 45: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 36 -

La version 1.0 de ce simulateur a été initialement développée au Laboratoire National

de Lawrence Berkeley (LBNL). Il fait actuellement partie du projet VINT (Virtual

InterNetwork Testbed) sous lequel la deuxième version (NS2) est sortie.

Le projet VINT est dirigé par l’université de Californie du sud et est financé par le DARPA en

collaboration avec Xerox PARC et LBNL. Il est utilisé par plusieurs groupes de travail

comme l’IETF pour évaluer les protocoles en cours de normalisation.

2.3 Fonctionnement de NS2 NS2 est un outil de recherche très util pour le design, la validation et l'évaluation des

protocoles.

Le simulateur utilise le langage orienté objet OTCL dérivé 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 réseau, les caractéristiques des liens physiques, les

protocoles utilisés, le type de trafic généré par les sources, les événements, etc.

Si le script écrit en OTCL permet une utilisation (édition, modification des simulations) 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.

Page 46: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 37 -

Figure 3.4 : Les étapes d’une simulation sur NS2

Avant de lancer une simulation, on introduit les paramètres de la simulation dans NS

grâce aux scripts TCL. Les paramètres consistent notamment en le nombre de nœud, les liens,

les protocoles mis en œuvre, les différents événements qui vont survenir, etc. Cette phase est

en fait une phase de description du scénario de simulation.

Les outputs des simulations sont des fichiers textes qu’on appelle fichiers trace. Ces

fichiers sont structurés en entrées. Chaque entrée correspond à une action effectuée par un

nœud (envoie de paquet, rejet de paquet, mise en file d'attente, réception d'un paquet). A titre

d'exemple, soit l'entrée suivante :

r 5.213 2 1 cbr 500 ------- 3 3.0 0.0 21 305

Cette entrée traduit la réception (r) à l'instant (5.213)s d'un paquet de type (cbr) de

taille (500) octets, de numéro d'identité (305), de numéro 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).

Script OTCL (description de scénario) - Topologie - Caractéristiques des nœuds - Caractéristiques des liens - Protocoles utilisés - Type de trafic généré - Evènements (envoie de paquet,

rupture de liens, changement de mode de routage, etc.)

- Etc.

Code en C++ (description des routines) - L’implémentation des algorithmes

(de routage, de file d’attente, …) - L’implémentation des modélisations

des liens physiques - L’implémentation de la procédure

d’encapsulation - Etc.

Simulation

Animation Nam : Visualisation des différents évènements du scénario de la simulation.

Fichier trace : Description textuelle des évènements relatifs à la simulation.

Filtrage, courbe et analyse des résultats : (AWK, XGraph, etc.)

Page 47: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 38 -

Ces fichiers doivent être traités pour pouvoir calculer les valeurs de bande passante,

perte, délai et gigue relatives au scénario en question. Par exemple, pour calculer le taux de

perte, il suffit de compter les entrées commençant par « d » (drop=rejeté) et les entrées

commençant par « r » (received=reçu), et ainsi extraire le taux de perte. Ce traitement a été

réalisé par le langage de traitement des fichiers : AWK.

Enfin, le traçage des courbes a été réalisé par Xgraph.

Par ailleurs, le simulateur permet la création d'un fichier d'animation permettant de

visualiser la simulation sur une interface graphique appelée NAM.

2.4 Les modifications à apporter à NS2

Les simulations ont été faite sur un processeur Intel Pentium III à 600MHz, 128Mo de

RAM, exécutant Linux Red Hat 9.0.

La version utilisée de NS est 2.26. Cette version ne supporte pas les protocoles relatifs

à MPLS. On a alors dû implémenter un ensemble de modules en extension à NS2.26 pour

faire de sorte que ce dernier puisse simuler les fonctions MPLS.

Les modules ajoutés sont les suivants :

• MPLS Network Simulator (MNS v2.0)

Ce module [10] est développé par Gaeil Ahn et Woojik Chun, Department of

Computer Engineering, Chungnam National University, Koreo.

Il permet à NS2 de prendre en charge des routines relatives à MPLS tel que : la

manipulation de label, la commutation de label, etc.

• Weighted Fair Queuing (WFQ)

Ce module [11] est développé par Paolo Losi et mis à jour par Sayenko Alexander,

Telecommunication laboratory, MIT department, University of Jyvaskyla, Finland.

Page 48: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 39 -

Il permet de différencier les flux en attribuant à chaque trafic un poids (weight) qui

reflétera son niveau de priorité.

• RSVP/ns

Ce module [12] est développé par Marc Greis, Computer Science Department IV,

University of Bonn.

C'est une implémentation du protocole de réservation de ressource RSVP.

• RSVP-TE/ns

Ce module [13] est développé par Christian Callegari et Fabio Vitucci, Dept. of

Information Engineering, University of Pisa, ITALY.

Cette implémentation contient la prise en charge des fonctions de Traffic Engineering

pour le protocole RSVP.

• le compilateur GNU C/C++ (GCC 2.95)

Le compilateur GCC est installé par défaut avec Linux. Cependant, dans la plupart des

cas la version qui est livrée avec la distribution Linux est soit GCC 2.96, soit GCC 3.x.

Le problème c'est que la première présente beaucoup de bugs et la deuxième a subi

tellement de modifications qu'elle ne supporte plus les modules qu'on va implémenter

dans NS2. Ceci nous a conduit à changer la version du compilateur par défaut par la

version 2.95.3.

2.5 Avantages, limites et difficultés de NS2 Comme tout outil de simulation, NS2 permet l’étude de l’existant, la conception, la

validation et l’évaluation de performances et ceci dans le domaine des protocoles et

mécanismes réseau. C’est un simulateur extrêmement flexible. NS2 permet l’étude des cas

difficiles à reproduire dans la réalité. Il offre la souplesse de pouvoir varier aisément une

multitude de paramètres du réseau (ce qui n’est pas le cas si on simule sur un réseau réel).

Donc, par rapport à l’expérimentation sur un réseau réel, NS2 permet un gain de temps et

d’argent.

Page 49: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 40 -

D’un autre côté, NS2 souffre des inconvénients des simulateurs tel que la

simplification et l’abstraction du monde réel, la difficulté (voire l’impossibilité) de tester

certains aspects, et la puissance de calcul requise qui croit exponentiellement avec la

complexification du système simulé. De plus, NS2 souffre de l’état primitif aussi bien de ses

outils de collecte et traitement des résultats 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 trouvés et

d'autres constamment introduits par les programmeurs. Finalement, on remarque souvent des

problèmes d'incompatibilité entre les implémentations de NS, les modules développés pour

NS et les versions de linux.

Dans le cas de notre projet, c'est surtout les deux derniers points qui ont présenté une

difficulté de taille pour l'avancement de notre travail d'autant plus que la documentation

manque sévèrement : généralement, les modules qui sont développés pour NS2 sont en étroite

dépendance avec les systèmes sur lesquels ils ont été développés initialement. De ce fait, il a

fallu constamment faire face à des problèmes d'incompatibilité et de réadaptation des modules

pour qu'ils puissent fonctionner sur la machine qu'on utilise. On a dû passer par une série de

test (implémentation de plusieurs modules, introduction de plusieurs modifications, test de

plusieurs combinaisons) et consulter une multitude de documentation concernant la

manipulation du système 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 problèmes.

L'établissement d'une procédure 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

préliminaire pour notre projet (à savoir l'évaluation des performances de MPLS TE), elle a

comme même été très enrichissante du point de vu expérience dans le débuggage et la

manipulation de Linux.

3 Simulation des fonctionnalités de MPLS TE

3.1 Le scénario de simulation On se propose de mettre en évidence les fonctionnalités de MPLS TE en utilisant

RSVP TE comme protocole de distribution de label.

Page 50: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 41 -

Pour cela, on a adopté une topologie et un scénario qui permet d'expliciter le plus

clairement possible le concept de TE.

La topologie est constituée de 13 nœuds connectés comme indiqué sur la figure 3.5.

Figure 3.5 : La topologie de simulation visualis ée par NAM

Le scénario est le suivant : Les nœuds 0, 1 et 2 sont configurés pour être des

générateurs de trafic. Les nœuds 11, 12 et 13 sont configurés pour recevoir le trafic, l'analyser

et ainsi pouvoir renseigner sur les paramètres à mesurer (Bande passante, Perte, Délai, Gigue).

Tous les autres nœuds (3..10) sont des LSR configurés pour supporter le protocole RSVP TE.

Enfin, tous les liens de la topologie sont dotés d'une bande passante de 2Mbps.

Les caractéristiques des flux qui vont traverser cette topologie sont explicitées dans le

tableau 3.2 :

Nœud

source

Nœud

destination

Taille des

paquets (octet)

Débit

(Mbps) Type du trafic

Couleur dans

l'animation NAM

0 11 500 1.8 Temps réel (TR) Bleu

1 12 500 1.3 Haute priorité (HP) Vert

2 13 500 0.6 Best Effort (BE) Rouge

Tableau 3.2 : Les flux considérés dans la simulation

Le trafic temps réel est généralement un trafic voix ou vidéo. Le trafic haute priorité

peut véhiculer par exemple une application interactive. Quant au trafic best effort, il peut

englober les services mail, transfert de fichier (FTP), etc.

Page 51: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 42 -

Le timing de la simulation est détaillé dans le tableau 3.3 :

Instant (s) Evénement LSP 0 Début de la simulation

0.2 Début de génération des trafics par les nœuds 0, 1 et 2

6 Activation de la fonction TE pour le nœud 0 (établissement d'un LSP)

0_3_4_10_11

6 Activation de la fonction TE pour le nœud 1 (établissement d'un LSP)

1_5_6_7_9_10_12

7 Activation de la fonction TE pour le nœud 2 (établissement d'un LSP)

2_5_6_7_8_10_13

9 Désactivation de la fonction TE pour le nœud 1 (Libération du LSP)

11 Réactivation de la fonction TE pour le nœud 1 (rétablissement du LSP)

13

Provocation d'une rupture dans le lien entre les noeuds 7 et 8. Ce qui provoque une procédure automatique de reroutage du trafic venant du nœud 2 et l'établissement d'un nouveau LSP contournant ainsi le lien rompu

2_5_6_7_9_8_10_13

15 Fin de la simulation

Tableau 3.3 : Timing de la simulation

3.2 Résultats de la simulation et interprétations La simulation décrite ci-dessus a permis de tracer des courbes relatives à chacun des

trois trafics mis en œuvre :

• Le trafic temps réel entre les nœuds 0 et 11

• Le trafic haute priorité entre les nœuds 1 et 12

• Le trafic best effort entre les nœuds 2 et 13

Pour chacun de ces flux, on va mesurer la variation par rapport au temps des quatre

paramètres de QoS à savoir : la bande passante, le taux de perte, le délai de bout en bout et la

gigue.

On rappel qu'on va utiliser les abréviations suivantes (voir tableau 3.2) :

• TR : Le flux Temps Réel

• HP : Le flux Haute Priorité

• BE : Le flux Best Effort

Page 52: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 43 -

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

Figure 3.6 : Bande Passante

Figure 3.7 : Taux de paquets perdus

Haute priorité (HP )

Temps réel (TR)

Best effort (BE)

Haute priorité (HP )

Temps réel (TR)

Best effort (BE)

Page 53: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 44 -

Pour commenter ces courbes, on va procéder par intervalles de temps. Chaque

intervalle de temps correspondant à un événement 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 reçu une bande passante de 1.2

Mbps, HP a reçu 0.6 Mbps et BE a reçu 0.2 Mbps (Voir figure 3.6). Ceci correspond à un

routage classique avec prise en compte des priorités 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 assignées au trois flux est égale

à 2 Mbps soit la capacité maximale du lien de transmission. La bande passante demandée

étant plus grande (3.7 Mbps), 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

Page 54: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 45 -

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

reçu la totalité du débit qu'ils sollicitent. Ceci induit évidement à l'annulation de leur taux de

perte (Voir Figure 3.7). Le flux BE entrent en compétition pour le même média avec le flux

TR, cela dit, il ne reçoit que ce qui reste de la bande passante (0.2 Mbps à la stabilité) vu que

sur ce lien, TR a fait une réservation préalable et est donc prioritaire. Le taux de perte relatif à

BE reste bien évidemment élevé.

Entre l'instant 6 et 7, on remarque un pic au-delà de 1.8 Mbps pour la bande passante de

TR. Le débit supplémentaire 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 intéressant ici d'observer la différence 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 façon explicite que le routage

classique ne permet pas une utilisation optimale des liens du réseau : 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 problème ;

puisque, comme c'est démontré par cette simulation, TE permet un équilibrage de charge

optimal sur tous les liens du réseau et une satisfaction totale des exigences des trois trafics en

terme de bande passante.

Page 55: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 46 -

Finalement, entre les instants 7 et 8 et pour le flux BE, on remarque un pic dépassant 0,6

Mpbs. Ce débit supplémentaire 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 réalise une libération du LSP relatif au trafic HP. Ce flux subit alors un

routage classique et empreinte par conséquence 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 deuxième lieu par rapport à TR vu

que ce dernier a réservé 1.8Mbps sur ce lien. HP se contente alors des 0.2 Mbps qui reste

(Voir figure 3.6). En résultat, on remarque une augmentation de 84% de taux de perte pour

HP, schématisé par un débordement 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 réactivant le TE pour HP on retrouve le rééquilibrage des charges sur les liens du

réseau 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).

Page 56: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 47 -

• 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 conséquente du taux de perte (Voir

figure 3.7). Juste après, il y a eu établissement d'une nouvelle LSP (Voir figure 3.13 (2))

permettant de nouveau un équilibrage optimal des charges sur le réseau.

En attendant que RSVP TE termine la procédure de reroutage, le flux BE a subi 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.

Page 57: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 48 -

3.2.2 "Délai de bout en bout" et "Gigue"

Figure 3.14 : Délai de bout en bout

Figure 3.15 : Gigue relatif au trafic TR

Haute priorité (HP )

Temps réel (TR)

Best effort (BE)

Page 58: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 49 -

Figure 3.16 : Gigue re latif au trafic HP

Figure 3.17 : Gigue relatif au trafic BE

Haute priorité (HP )

Temps réel (TR)

Best effort (BE)

Page 59: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 50 -

• L'intervalle [0.2s .. 6s]

Dans cet intervalle le délai est presque identique pour les 3 flux (TR : 90ms ; HP,BE :

100ms). TR profite d'un débit meilleur parce qu'il est privilégié dans la file d'attente.

La gigue est stable (RT : jusqu'à ms, HP : jusqu'à 2.2ms, BE : jusqu'à 1.0ms). La

présence de la gigue est due essentiellement à la file d'attente dans le nœud 3. Elle est très

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 régularité 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 fait que leur délai de bout en bout s'est nettement

amélioré (amélioration de 30ms pour HB et de 40ms pour TR (voir figure 3.14)). Le flux BE

voit sont délai augmenter exponentiellement vu qu'il empreinte un chemin réservé par TR.

En ce qui concerne HP, l'amélioration de la gigue est nette (0.1ms au lieu de 2.2ms). On

peut même dire que ce trafic ne présente 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'amélioration du délai relatif à TE n'a pas empêché sa gigue d'augmenter de 0.2ms. Mais une

telle augmentation n'a pas d'incidence sur les applications temps réel.

• L'intervalle [7s .. 9s]

L'établissement d'un LSP pour le flux BE a amélioré son délai qui est devenu égal à celui

de HP (70ms), puisque ces deux trafics empruntent des LSP de même longueur.

Page 60: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 51 -

Figure 3.19 : Zoom relatif à la courbe de délai entre les instant 8.5s et 8.85s

On remarque sur la courbe des délais la présence d'une petite variation périodique

relatif aux flux HP et BE (Voir figure 3.19). Ceci est dû au fait que ces deux trafics

empruntent des chemins sécants. C'est ce qui explique la légère 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 disparaît pour le trafic TR.

• L'intervalle [9s .. 11s]

La désactivation du LSP de HP fait qu'il est routé sur le même chemin que TR. Or TR a

réservé sont chemin donc il est prioritaire. C'est pourquoi son délai est resté le même. Cela dit,

la courbe de délai relative à TR n'est plus constante mais oscille légèrement autour de sa

moyenne (Voir figure 3.14). Ceci est dû au partage du média avec le flux HP. Il en résulte une

augmentation faible de la gigue de TR (0.3ms).

HP n'est servi qu'en dernier lieu. Son délai augmente alors exponentiellement pour atteindre

460ms, et sa gigue se détériore pour atteindre 0.9ms.

La gigue du trafic BE s'est bien sûr améliorée puisque BE utilise seul le média.

• L'intervalle [11s .. 13s]

Le rétablissement du LSP de HP a rétabli les paramètres à leur état initial.

• L'intervalle [13s .. 15s]

Jusqu'à l'instant 13,2s, BE observe une augmentation brusque du délai et de la gigue. Ceci

est dû à la rupture du lien entre les nœuds 7 et 8 et au temps que prend la procédure de

reroutage (recherche et établissement d'un nouveau LSP optimal).

Page 61: Mpls foudhaili oussama

Chapitre III : Implémentation et simulation des fonctionnalités de MPLS TE

- 52 -

Cette panne a profité pour HP dont la gigue s'est améliorée pendant ces 0.2s. Le contraire

s'est produit pour TR qui a dû partager les liens qu'il utilise avec BE pendant la durée de

reroutage.

A partir de l'instant 13.2, on observe une re-stabilisation des délais 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 intéressant de remarquer que, durant toute la période de simulation, la gigue relative

au flux TR ne dépasse jamais 0.3ms. Ceci est très important pour un trafic temps réel (voix,

vidéo). HP et BE atteignent parfois les 5ms de gigue mais ça n'a pas grande importance vu la

nature de leurs applications.

Conclusion Les simulations que nous avons réalisées ont mis en évidence le besoin d'intégrer des

mécanismes aux réseaux 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 montée

efficace et surtout simple à mettre en œuvre et très souple à manipuler. Elle permet de réaliser

un équilibrage de charge sur l'ensemble du réseau et de prendre des décisions de re-routage ;

ce qui se traduit par une utilisation plus optimale des ressources et une satisfaction plus

grandes des demandes des applications.

Page 62: Mpls foudhaili oussama

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom"

- 53 -

Chapitre IV : Evaluation des performances

de MPLS TE sur le backbone de "Tunisie Télécom"

Introduction On a déjà évoqué les avantages économiques qu'implique l'exploitation d'un seul

réseau pour plusieurs applications, et le gain qui pourra résulter du remplacement de la

commutation de circuit par la commutation de paquet.

En suivant cette logique, Tunisie Télécom s'est fixé le but d'avoir (dans le court/moyen

terme) un réseau national unique pour véhiculer à la fois le trafic voix (à ce jour réalisé par un

réseau à commutation de circuit) et le trafic de donnée (réalisé par la commutation de paquet

et/ou de cellule).

Ceci vient en conformité avec la logique de baisse des tarifications des Télécom. De

plus, migrer vers un tel réseau permettra d'offrir une infrastructure plus encourageante à

l'informatisation des entreprises et des particuliers. Ce qui contribuera à l'instauration de la

"Société de l'Information".

On a vu dans le chapitre III qu'il est inévitable de passer par le "Traffic Engineering"

pour optimiser l'utilisation d'un réseau afin qu'il soit apte à véhiculer 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 Télécom, ceci en utilisant la simulation sur NS2 comme outil d'étude.

1 Description du backbone MPLS de Tunisie Télécom 1.1 Définition de Backbone

Un backbone est un ensemble d'artères longues distances, à très haut débit de

transmission, qui relient les principaux nœuds d'un réseau étendu. Le backbone constitue le

cœur du réseau, sur lequel des liaisons de plus faibles capacités de transmission sont

raccordées. Ces liaisons servent à interconnecter des réseaux plus petits (internes à une

Page 63: Mpls foudhaili oussama

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom"

- 54 -

entreprise ou à une région). On peut faire l'analogie des petits réseaux se rattachant à un

backbone, avec des rivières qui viennent grossir le cours d'un fleuve.

Les liens qui forment le backbone sont constitués majoritairement de câbles à fibres

optiques installés sous les océans et sur les continents.

On distingue les réseaux backbone nationaux (échelle d'un pays), régionaux (échelle

d'un groupe de pays) ou mondiaux (échelle de la planète). Dans notre cas, on s'intéressera au

backbone national de Tunisie Télécom.

1.2 Structure du backbone de Tunisie Télécom Le backbone qu'on va utilisé comme base pour nos simulations est le suivant :

Figure 4.1 : La structure du backbone de Tunisie Télécom

Il est constitué de :

• 9 LSR :

– Quatre se trouvent dans le grand Tunis et plus précisément à Kasbah, Hached,

Belvédère et Ouardia ;

– Cinq sont dans les villes de Sfax, Sousse, Béja, Kairouan et Gabes.

• 18 LER :

– Neuf sont co-localisés avec les LSR ;

– Neuf sont à Marsa, Ariana, Menzeh, Ben Arous, Bardo, Bizerte, Nabeul,

Moknine et Gafsa.

Cette architecture ne fait pas partie du cahier des charges de notre projet.

Comme on peut le constater, chaque LSR est co-localisé avec un LER. Pour la

commodité de la représentation, on schématisera chaque couple LSR/LER co-localisé par un

seul routeur.

9 LSR

18 LER

Page 64: Mpls foudhaili oussama

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom"

- 55 -

La figure 4.2 montre la disposition géographique du backbone.

Figure 4.2 : La disposition géographique du backbone de Tunisie Télécom

Pour mieux apprécier cette topologie, on va plutôt considérer la disposition de la figure 4.3 :

Figure 4.3 : Backbone de Tunisie Télécom

LER

LER/LSR

STM-4

2 STM-4

STM-16

Bizerte

Béja

Kairouan

Gafsa

Gabés

Sfax

Nabeul

Moknine

Grand Tunis

Sousse

Ariana

Bardo

Gabès

Gafsa

Kairouan

Béja

Moknine Bizerte Nabeul Ben Arous Marsa

Menzeh

Hached

Belvédère

Sousse

Sfax

Kasbah

Ouardia

Page 65: Mpls foudhaili oussama

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom"

- 56 -

Le backbone contient 3 types de liens :

• STM-4 : format SDH de transmission sur fibres optiques avec une bande passante de

622.08 Mbps ;

• 2 STM-4 : format SDH de transmission sur fibres optiques avec une bande passante de

1244.16 Mbps ;

• STM-16 : format SDH de transmission sur fibres optiques avec une bande passante de

2488.32 Mbps.

Chacun des 18 nœuds MPLS du backbone reçoit un "flux voix" et un "flux donnée". Le

tableau 4.1 illustre les capacités des liens raccordés au backbone selon le type de trafic qu'ils

véhiculent :

Site Capacité du lien dédié au trafic "Voix" (Gbps)

Capacité du lien dédié au trafic "Donnée" (Gbps)

Ariana 1 2

Bardo 1 3.1

Béja 1 1.1

Belvédère 2 2

Ben Arous 2 5

Bizerte 1 1.6

Hached 2 2

Kairouan 1 1.1

Kasbah 2 1.1

Marsa 2 1

Menzeh 1 2

Moknine 1 1

Nabeul 2 3.3

Ouardia 2 2

Sfax 2 4.9

Sousse 2 3.5

Gabés 1 1

Gafsa 1 0.9

Tableau 4.1 : Descriptif des liens raccordés au backbone

Page 66: Mpls foudhaili oussama

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom"

- 57 -

2 Simulation et résultats

2.1 Scénario de la simulation

Afin d'évaluer l'apport de la technologie MPLS TE sur le backbone de Tunisie

Télécom, Nous avons procédé à l'implémentation de la topologie sur NS2 (Voir Figure 4.4).

Figure 4.4 : le backbone tel que généré par NS2

La modélisation des distances :

La transmission des données sur fibre vérifie la loi : td

c =

Avec c : célérité = 3 108 m/s

d : longueur de la fibre

t : délai de propagation

Ainsi, pour avoir 1ms de délai de propagation, il faut 300Km de fibre. Or dans le

backbone étudié, les deux nœuds les plus éloignés et qui sont directement liés sont à 406Km

(Hached-Gabés). Etant donnée que le délai de bout en bout est généralement de l'ordre de

plusieurs dizaines de ms, le délai de propagation (qui constitue une des composantes du délai

de bout en bout) peut être négligé dans la simulation. Donc, au niveau du territoire national,

les distances n'ont pas grande influence sur le délai de bout en bout.

Description du trafic simulé :

On configure certains nœuds du backbone pour qu'ils génèrent deux types de trafics :

• Un trafic voix dont le débit est équivalent au quart (1/4) de la capacité du lien dédié au

trafic "Voix" entrant au backbone (Voir Tableau 4.1) ;

• Un trafic donnée dont le débit est équivalent au tiers (1/3) de la capacité du lien dédié

au trafic "Donnée" entrant au backbone (Voir Tableau 4.1) ;

Page 67: Mpls foudhaili oussama

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom"

- 58 -

Chaque trafic entrant (voix et donnée) est véhiculé à travers le backbone vers les différents

LER.

2.2 Résultats et interprétations

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 exprimée en pourcentage de la bande passante utilisée. En d'autres termes :

liendu Passante Bandelien cesur envoyéDébit

lien un d' Occupation =

Par exemple, si on envoie un débit 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 résume l'ensemble des mesures effectuées sur l'occupation des liens. Les

mesures ont été faites :

– Une première fois avec le backbone fonctionnant en mode IP classique ;

– Une deuxième fois avec le backbone fonctionnant en mode MPLS TE.

Occupation du lien (%) Lien Type du lien Mode

IP classique Mode

MPLS TE Bardo Belvédère 2 STM-4 56 62 Bardo Kasbah 2 STM-4 54 77 Ariana Belvédère 2 STM-4 58 63 Ariana Kasbah 1 STM-4 55 68 Menzeh Hached 2 STM-4 45 66 Menzeh Belvédère 2 STM-4 46 68 Marsa Hached 2 STM-4 38 70 Marsa Ouardia 1 STM-4 35 69

Ben Arous Hached 2 STM-4 88 90 Ben Arous Ouardia 2 STM-4 85 96

Nabeul Ouardia 2 STM-4 59 76 Nabeul Sousse 2 STM-4 62 90 Bizerte Ouardia 2 STM-4 54 76 Bizerte Béja 1 STM-4 50 53

Moknine Sousse 2 STM-4 36 80 Moknine Sfax 1 STM-4 32 75

Page 68: Mpls foudhaili oussama

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom"

- 59 -

Gafsa Sfax 2 STM-4 35 70 Gafsa Gabés 2 STM-4 48 83

Hached Ouardia 1 STM-4 100 81 Ouardia Kasbah 1 STM-4 100 79 Kasbah Belvédère 1 STM-4 100 85

Belvédère Hached 1 STM-4 100 74 Hached Kasbah 1 STM-16 95 88 Hached Sfax 1 STM-16 98 86 Hached Gabés 1 STM-16 100 84

Belvédère Ouardia 1 STM-16 100 90 Belvédère Sousse 1 STM-16 100 91

Kasbah Sfax 1 STM-16 96 97 Kasbah Kairouan 1 STM-16 100 92 Ouardia Sousse 1 STM-16 100 89 Ouardia Béja 1 STM-16 100 93

Sfax Gabés 1 STM-16 87 76 Sfax Kairouan 1 STM-16 83 88 Sfax Sousse 2 STM-4 /1 STM-16 100 92

Kairouan Sousse 2 STM-4 100 83 Béja Kairouan 1 STM-4 / 1 STM16 77 70

Tableau 4.2 : L'occupation des liens

Ce tableau, présenté ainsi, n'est pas très parlant. Pour cela, on a rapporté ces mesures

directement sur le schéma 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%

Page 69: Mpls foudhaili oussama

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom"

- 60 -

La figure 4.6 traduit un certain équilibrage des charges sur tout le backbone et du coup

une utilisation plus optimale des ressources du réseau (presque tous les liens sont orange).

Cette performance a été rendue possible grâce à l'utilisation du Traffic Engineering.

La figure 4.5 montre l'existence de plusieurs liens saturés, alors que d'autres liens sont

sous-utilisés. Ceci s'explique par le fait que le routage IP classique ne prend pas en

considération les capacités disponibles des liens, puisque son seul critère est la recherche du

plus court chemin. Donc, pour router les paquets, il a tendance à sur-utiliser les nœuds

LER/LSR et donc à saturer les liens STM-16 bien qu'il aurait pu utiliser des routes -

évidement plus longues et de plus fiables capacités - mais ayant de la bande passante non

utilisée. 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 Belvédère à 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 délais très importants.

Figure 4.7 : Exemple de route IP

D'un autre côté, des liens rattachant des nœuds comme Nabeul et Ben Arous peuvent

être partiellement disponibles et donc peuvent véhiculer le trafic de Moknine jusqu'à Ariana

(Voir Figure 4.8).

Moknine

Ariana

Belvédère

Sousse

Page 70: Mpls foudhaili oussama

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom"

- 61 -

Figure 4.8 : Exemple de route MPLS TE

IP classique est incapable de prendre une décision de re-routage de trafic à travers une

route plus longue même 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 délai

On va essayer d'apprécier l'impacte que peut avoir l'utilisation de MPLS TE sur le

paramètre délai. Pour cela, on va mesurer "le délai normalisé par le nombre de saut". C'est-à-

dire que pour chaque paquet reçu, on mesure son délai 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 :

Saut de Nombrebouten bout de Délai

saut de nombre lepar normalisé Délai =

Ce paramètre reflète en réalité le temps de séjour moyen d'un paquet dans une file

d'attente (puisque le délai de propagation et les autres composantes du délai sont

négligeables).

La figure 4.9 représente les courbes relatives aux délais. Les mesures ont été faites :

– Une première fois avec le backbone fonctionnant en mode IP classique : Dans ce cas

les trafics Voix et Donnée sont traités de la même manière, puisqu'il n'y a pas un

Moknine

Ariana

Nabeul

Belvédère

Hached

Ben Arous

Sousse

Ouardia

Page 71: Mpls foudhaili oussama

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom"

- 62 -

mécanisme de classification. C'est pour ça qu'on a représenté une seule courbe de délai

pour les deux trafics (courbe bleu).

– Une deuxième fois avec le backbone fonctionnant en mode MPLS TE : Dans ce cas,

on a un traitement différent du trafic Voix et du trafic Donnée. Donc on a représenté

deux courbes de délai relatives chacune à un type de trafic (courbe rouge et verte).

Figure 4.9 : Délai normalis é par le nombre de saut

On remarque que pour le mode IP, on a un délai qui varie autour de 70ms. Lorsqu'on

passe au mode MPLS TE, on observe une différence nette entre le délai moyen du trafic

Donnée et le délai moyen du trafic Voix. Le trafic Voix observe une chute de délai

considérable pour atteindre une moyenne de 35ms. Cette valeur est assez satisfaisante pour le

transfert de la voix. Puisque en regardant le backbone, on s'aperçoit que les deux destinations

les plus éloignées sont distantes de 4 sauts. Donc si le processus MPLS TE privilégie le trafic

Voix et lui assigne assez souvent le plus court chemin, ce trafic aura un délai de bout en bout

ne dépassant pas les 140ms (35*4). Ce qui est acceptable en téléphonie vu qu'on tolère jusqu'à

150ms de délai.

Quant au trafic Donnée, sont délai augmente jusqu'à une moyenne de 105ms. Ce qui

n'est pas très handicapant pour les services Donnée

D'un autre côté, il est intéressant de remarquer qu'en passant vers le mode MPLS TE,

la marge de fluctuation des courbes de délai a diminué considérablement surtout pour le trafic

Voix. Ceci traduit l'équilibrage des charges dans les files d'attente

Trafic Donnée - mode MPLS TE

Trafic - mode IP

Trafic Voix - mode MPLS TE

Page 72: Mpls foudhaili oussama

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom"

- 63 -

2.2.3 Estimation du taux de perte

Pour l'estimation des pertes, on a suivi la même approche que pour le délai. 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 Donnée en utilisant 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 véhiculer correctement le trafic Voix, puisqu'en téléphonie le seuil

maximum permis est de 2%.

Le taux de perte est presque nul lorsque le réseau utilise le mode MPLS TE. Ceci est

conforme au résultat obtenu pour l'estimation des charges des liens, puisque ces derniers sont

tous non saturés (Voir Figure 4.6).

Conclusion Les simulations que nous avons réalisées sur le backbone de Tunisie Télécom 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 véhiculer du multiservice. Ensuite, MPLS TE est

une approche qui s'est montrée très performante quant à l'optimisation de l'utilisation des

ressources du réseau, d'autant plus qu'elle permet la transmission de trafic multiservice en

respectant les exigences des différentes applications.

Trafic Donnée - mode MPLS TE

Trafic - mode IP

Trafic Voix - mode MPLS TE

Page 73: Mpls foudhaili oussama

Chapitre IV : Evaluation des performances de MPLS TE sur le bockbone de "Tunisie Télécom"

- 64 -

Enfin, il est intéressant de remarquer qu'un taux de perte de 0% dépasse de loin les

paramètres 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 dépasser les seuils des

exigences respectives des applications. Et ainsi réaliser des gains économiques.

Page 74: Mpls foudhaili oussama

Conclusion générale

- 65 -

Conclusion générale

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 thématique en commençant par une étude théorique 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 présenté

les applications qu'il permet de réaliser. Dans le chapitre II, nous nous sommes penchés sur

l'une des plus importantes applications de MPLS à savoir la prise en charge du "Traffic

Engineering" et nous nous sommes concentrés dans cette partie sur l'étude du protocole de

distribution de label RSVP TE.

Ceci nous a préparé à la deuxième phase de ce projet qui est la simulation du

fonctionnement de MPLS. Nous avons pour cela préparer l'environnement de simulation NS2

pour qu'il soit capable de prendre en charge les mécanismes et protocoles relatives à MPLS

(en particulier RSVP TE).

Ainsi, nous avons dans le chapitre III, réussi à implémenter un réseau MPLS et à

simuler quelques unes de ses fonctionnalités telles que la création de LSP, la réservation de

ressources ou le re-routage en cas de pannes. Nous avons aussi réalisé un ensemble de

mesures qui ont permis d'aboutir aux conclusions suivantes :

D'abord, contrairement à l'IP classique, MPLS TE privilégie le choix des chemins à

disponibilité suffisante plutôt que les chemins les plus courts. Les courbes de Bande passante,

perte, délai et gigues que nous avons dressées ont montré le bien fondé de cette approche.

Ensuite, MPLS TE permet de garantir une qualité de service minimale à une

application donnée grâce au mécanisme de réservation de ressource qu'opère 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 réseau grâce à sa fonction de re-routage.

Enfin, On peut affirmer que MPLS TE permet d'atteindre un haut niveau

d'optimisation de réseau et de satisfaire ainsi plus efficacement les demandes des applications

rendant possible de véhiculer plusieurs types de trafic sur un réseau IP.

Dans le chapitre IV, nous avons essayé d'évaluer l'apport qu'aura l'intégration de

l'approche TE dans le backbone de Tunisie Télécom. Nous avons montré que le routage

Page 75: Mpls foudhaili oussama

Conclusion générale

- 66 -

classique ne permet pas de véhiculer voix et donnée sur le même réseau. Alors qu'en utilisant

le TE on a pu réaliser un certain équilibrage de charges sur les liens du backbone et ainsi

améliorer nettement les paramètres de perte et de délai. Le "Traffic Engineering" réalise une

répartition plus fine des ressources dans le réseau de l'opérateur permettant d'un côté d’éviter

le recours à une politique de surdimensionnement des réseaux physiques et d'un autre côté

d’associer voix/donné sur le même backbone

On propose comme travail complémentaire de réaliser une application d'optimisation

du réseau basée sur des algorithmes méta-heuristiques. On imposera comme contraintes :

• Les seuils de QoS (délai, perte, gigue, etc.) permis pour chaque type de trafic ;

• Les capacités des liens ;

• Les statistiques relatives au trafic national.

On aura comme résultat un câblage optimal du backbone MPLS avec un maximum

d'économie sur les liens.

Plusieurs autres domaines et axes de recherche intéressants liés à 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'amélioration des mécanismes de files d'attente utilisés ;

• MPLS VPN ;

• GMPLS, qui est une généralisation de MPLS pour supporter les réseaux optiques.

Page 76: Mpls foudhaili oussama

Références

- 67 -

Références [1] Jean-Louis Mélin, Qualité de service sur IP, Eyrolles, 2001 [2] Jean-Antoine Montagnon, T Huong Tran, MPLS et les réseaux d’entreprise, ON-X/Consulting, 2002 [3] Eric Osborne, Ajay Simha, Traffic Engineering with MPLS, Cisco Press, 2002 [4] Paul Brittain, Adrian Farrel, MPLS Traffic Engineering : a choice of signaling protocols, Data Connection Limited, 2000 [5] Guillaume aka guill, Nadim aka rusher, guill.net©1999-2005, http://www.guill.net/ [6] Cisco IP QoS Introduction, Copyright ?2001, Cisco Systems, Inc. [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/

Page 77: Mpls foudhaili oussama

Résumé

Le principe de "Best Effort" ne peut offrir aucune garantie de QoS pour les

exigences des nouvelles applications (vidéo, voix, etc). En même temps, il ne

serait pas raisonnable d'abandonner les réseaux IP qui sont tellement répandus

de nos jours. MPLS apporte une solution ingénieuse à ce problème et rend

ainsi possible le multiservice sur les réseaux IP. Cette technologie a réussi à

conjuguer la simplicité de IP avec la gestion de QoS d'ATM.

MPLS a permis entre autres de réaliser des applications comme le "Traffic

Engineering" qui permet d'accéder à un haut niveau d'optimisation des réseaux,

facilitant ainsi le passage au "tout IP".

Mot clés

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