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

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

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

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

-i-

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'environneme nt 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

- ii -

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

- iii -

Figure 3.16 : Gigue relatif au trafic HP .......................................................................49
Figure 3.17 : Gigue relatif au trafic BE .......................................................................49
Figure 3.18 : Zoom relatif à la courbe de gigue...........................................................50
Figure 3.19 : Zoom relatif à la courbe de 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

- iv -

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

-v -

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

- vi -

Introduction générale

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

-1-

Introduction générale

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.

-2-

Chapitre I : MultiProtocol Label Switching

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

Ingress LER
12.3.2.125

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

L=10921
LSR
LSR LSR

Figure 1.1 : Exemple 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.

-3-


• 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

-4-


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

-5-


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

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

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

ATM GFC VPI VCI PTI CLP HEC DATA

Label

Figure 1.2 : 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.

-6-


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.

10.2.0.174
10.2.0.174

Site 1 Site 2

3 1
9 2

6

4 2
Domaine MPLS
9 2
Opérateur

8 2
6 2

7 2

Figure 1.4 : Pile de labels

-7-


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.

Utilisez le label 25 pour la Utilisez le label 53 pour la
182.65.10/24 destination 182.65.10/24 destination 182.65.10/24 182.65.10/24

LSR A LSR B LSR C
Figure 1.5 : Unsolicited downsteam

-8-


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

Utilisez le label 25 pour la Utilisez le label 53 pour la
182.65.10/24 destination 182.65.10/24 destination 182.65.10/24 182.65.10/24

LSR A LSR B LSR C

Demande de label pour la Demande de label pour la
destination 182.65.10/24 destination 182.65.10/24

Figure 1.6 : Downsteam-on-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.

-9-


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

- 10 -


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 :

- 11 -


Protocole de
Espace de
distribution Contrôle Distribution Conservation Création
label
de label
Downstream Topology-
TDP et LDP Unordered Liberal Per platform
unsolicited based
TDP et LDP Downstream on Topology-
Ordered Conservative Per interface
(avec ATM) Demand based
Downstream on Request-
RSVP TE Ordered Conservative Per platform
Demand based
Unordered/ Downstream unsolicited/ Liberal/ Per platform/ Request-
CR-LDP
Ordered Downstream on Demand Conservative Per interface based

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

5 Les applications de MPLS
La motivation primaire de MPLS était 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.

- 12 -


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

- 13 -


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é.
VPN 2

LER
VPN 1
LER
VPN 2
LER

VPN 2
LER
VPN 1
LER

LER

VPN 1

Figure 1.7 : MPLS VPN

Il existe une autre approche permettant de mettre en œuvre des VPN sur les réseau IP :
IPSec. IPSec privilégie la sécurisation des flux 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.

- 14 -


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.

- 15 -

Chapitre II : MPLS Traffic Engineering

Chapitre II :
MPLS Traffic Engineering
(MPLS TE)

Introduction
Dans ce chapitre, on va commencer par expliquer la notion de Traffic Engineering et
les 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

Le chemin le plus court

R1
R5
Coût : 15
R6
R2 Coût : 15
Coût : 15

Coût : 15 Coût : 15
R7 Coût : 15

R3 R4
Coût : 15

Figure 2.1 : Le routage 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).

- 16 -


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 R envoie en moyenne 90Mbps
1
à R6. Le protocole de routage va faire de sorte que ce trafic utilise le plus court chemin, soit
R2 à R5 à R6. Si maintenant R7 veut envoyer 100Mbps à R6. La même procédure de
routage fera que ce trafic utilisera aussi le chemin e plus court. En final, on aura deux trafics
l
de 190Mbps en total qui veulent tous deux utiliser le chemin le plus court (R2 à R5 à R6),
alors que ce chemin ne peut supporter que 150Mbps. Ceci va induire des files d'attente et des
pertes de paquets. Cet exemple est un cas explicite de sous utilisation des ressources du
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

- 17 -


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

R1
LSR5
Coût : 15 LSR6
LSR2 Coût : 15
Coût : 15

Coût : 15 Coût : 15
R7
Coût : 15

LSR3 LSR4
Coût : 15

Tunnel2

Figure 2.2 : Le Traffic Engineering selon MPLS

La souplesse de 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.

- 18 -


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 p CSPF pour calculer un
ar
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).

- 19 -


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 fux donné). RSVP avec quelques extensions a été adapté par MPLS pour être un protocole
l
de signalisation qui supporte MPLS TE.

Nous allons, dans cette partie, commencer par illustrer le format général des messages
RSVP TE. Pour enfin expliquer avec plus ou moins de détails le fonctionnement de ce
protocole.

- 20 -


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
Analogue au message Path, mais utilisé pour supprimer les
PathTear
réservations du réseau
Analogue au message Resv, mais utilisé pour supprimer les
ResvTear
réservations du réseau
Envoyé par un récepteur d'un message Path qui détecte une erreur
PathErr
dans ce message
Envoyé par un récepteur d'un message Resv qui détecte une
ResvErr
erreur dans ce message
Optionnellement envoyé à l'émetteur d'un message Resv pour
ResvConf
confirmer qu'une réservation donnée est bien établie
Analogue à ResvConf. Optionnellement envoyé à l'émetteur d'un

ResvTearConf 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

- 21 -


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

Version Flags Message type RSVP checksum Common
Header
Send TTL Reserved RSVP length

Objects

Figure 2.4 : Format des messages RSVP 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 6 = ResvTear message
2 = Resv message 7 = ResvConf message
3 = PathErr message 10 = ResvTearConf message
4 = ResvErr message 20 = Hello message
5 = PathTear 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

- 22 -


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 n
umé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]
Common Header
SESSION [INTEGRITY]

PHOP SESSION

TIME_VALUES NHOP

[EXPLICIT_ROUTE] TIME_VALUES

[RESV_CONFIRM]
LABEL_REQUEST
Objets [SCOPE]
[SESSION_ATTRIBUTE]
[POLICY_DATA]
[POLICY_DATA]
STYLE
SENDER_TEMPLATE
FLOWSPEC
SENDER_TSPEC FILTER_SPEC

[ADSPEC] LABEL

[RECORD_ROUTE] [RECORD_ROUTE]

Figure 2.6 : Format du Path message Figure 2.7 : Format du Resv message

- 23 -


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

- 24 -


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

- 25 -


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

R1
R4
(10)
L=18 R6 (6)
L=implicit -null
(1) R2 R7

L=42 (5)
R8 (9) (7)
L=21 (4)
(2)
R3 (8) L=10921
R5

(3)
PATH

RESV

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

Supposant que R1 a déjà réalisé sa procédure CSPF et a déjà décidé des besoins en 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, R envoie un message d'erreur (PathErr) vers R Si tout se passe bien, on
2 1.
passe à l'étape (2)
(2) R2 envoie un Path message à R3. R3 fait les mêmes vérifications que dans l'étape(1)
(3) R3 envoie un Path message à R5. Réalisation des mêmes vérifications.
(6) R7, étant le tunnel tail, envoie un Resv message à R6. Ce Resv message contient le
label que R7 veut voir dans les paquets de ce tunnel. Puisque R est le tail, il envoie
7
un label= implicit-null=3.
(7) R6 envoie un Resv message à R5 et indique qu'il veut voir un incoming label 42 dans
les paquets de ce tunnel. Ceci veut dire que quand R reçoit le label 42, il enlève ce
6
label (à cause de l'implicit-null) et envoie le paquet vers R7.
(8) R5 envoie un Resv message à R3 et indique qu'il veut voir un incoming label 10921
dans les paquets de ce tunnel. Ceci veut dire que quand R reçoit un paquet de donnée
5
avec le label 10921, il le change (swapping) en 42 et envoie le paquet vers R6.

- 26 -


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

A ce stade, Le TE LSP est complètement établie entre R et R7. Le headend (R1) peut alors
1
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, R envoie un Path message à R2 pour la
1
réservation qu'il a effectué. Et chaque 30 secondes, R envoie un Resv message à R1 pour la
2
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.

- 27 -


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.

- 28 -


• 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 :

(1) (2)
LABEL REQUEST (B,C) LABEL REQUEST (C)

LSR A LSR B LSR C
Ingress LABEL MAPPING (17) LABEL MAPPING (32) Egress
(5) (4) (3)

Figure 2.9 : Etablissement 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.

- 29 -


(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".

- 30 -

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

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)

Terminal A Terminal B

10Mbps 128 kbps 100 Mbps 512 kbps

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

- 31 -


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 p traiter le paquet (la
as
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)

Terminal A Terminal B

Délai de Délai de Délai de Délai de
propagation propagation propagation propagation

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

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

- 32 -


• 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).

- 33 -


Emission

Réception

Gigue

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.

Bande Sensibilité à
Sensibilité au Sensibilité à
Type d'application passante la perte en
délai la gigue
requise paquets

Voix (VoIP) Elevé Moyenne Elevé Elevé

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

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

Non
Best effort (FTP) Moyenne Elevé Faible
importante

Non
Background (mail) Faible Elevé Faible
importante
Tableau 3.1 : Les exigences des différentes applications IP en terme de QoS

- 34 -


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

- 35 -

Mpls foudhaili oussama

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Mpls foudhaili oussama

Ähnlich wie Mpls foudhaili oussama (20)

Mehr von Gilles Samba

Mehr von Gilles Samba (18)

Mpls foudhaili oussama