N° d’ordre : 26 / RS / TCO Année Universitaire : 2012 / 2013

UNIVERSITE D'ANTANANARIVO
------------------------------
ECOLE SUPERIEURE POLYTECHNIQUE
-------------------------------
DEPARTEMENT TELECOMMUNICATION

MEMOIRE DE FIN D'ETUDES

en vue de l'obtention
du DIPLOME d’INGENIEUR
Spécialité : Télécommunication
Option : Réseaux et système

par : RAVOAVAHY Andriamparany Arnaud

ANALYSE DE PERFORMANCE DE LA VOIP SUR UN

BACKBONE MPLS AVEC TRAFFIC ENGINEERING
Soutenu le 06 Août 2014 devant la Commission d’Examen composée de :

Président :
Monsieur ANDRIAMIASY Zidora

Examinateurs :
Monsieur RANDRIARIJAONA Lucien Elino
Monsieur RAKOTONDRAINA Tahina Ezéchiel
Madame ANDRIANTSILAVO Haja Samiarivonjy

Directeur de mémoire :

Monsieur RAVONIMANANTSOA Ndaohialy Manda-Vy

 REMERCIEMENTS

Tout d’abord, je remercie le Tout Puissant pour sa grâce et sa bonté et qui m’a permis de réaliser
ce mémoire de fin d’études.

J’exprime ma gratitude envers Monsieur ANDRIANARY Philippe Antoine, Directeur de l’Ecole

Supérieure Polytechnique d’Antananarivo, pour mes cinq années d’études dans cet établissement.

Je tiens à témoigner ma profonde gratitude à Monsieur RAKOTOMALALA Mamy Alain, Chef de

Département Télécommunication, pour mes cinq années d’études dans ce département.

Mes vifs remerciements s’adressent également à Monsieur ANDRIAMIASY Zidora qui me fait
l’honneur de présider le jury de ce mémoire.

J’adresse également mes remerciements les plus sincères à Monsieur RAVONIMANANTSOA

Ndaohialy Manda-Vy, Directeur de ce mémoire de fin d’études, pour le temps qu’il m’a accordé,
pour son aide et ses conseils inestimables durant la préparation de ce travail.

Je témoigne toute ma reconnaissance aux autres membres du jury qui ont bien voulu examiner la
valeur de ce travail :
 Monsieur RANDRIARIJAONA Lucien Elino
 Monsieur RAKOTONDRAINA Tahina Ezéchiel
 Madame ANDRIATSILAVO Haja Samiarivonjy

Je tiens aussi à exprimer toute ma reconnaissance aux membres de ma famille, pour le soutien
qu’ils ont apporté tout au long de mes études. Je reconnais les sacrifices que ces longues années
ont représenté et je les remercie d'avoir toujours su m'encourager.

Enfin, je ne saurai oublier toutes les personnes qui m’ont aidé de près ou de loin dans
l’élaboration du présent mémoire.

ii
 TABLE DES MATIERES

REMERCIEMENTS ..................................................................................................................................... ii
TABLE DES MATIERES ........................................................................................................................... iii
NOTATIONS ............................................................................................................................................... vii
LISTE DES ABREVIATIONS.................................................................................................................... ix
INTRODUCTION GENERALE.................................................................................................................. 1
CHAPITRE 1 : GENERALITES SUR LA VOIP ...................................................................................... 2
1.1 Introduction ......................................................................................................................................... 2

1.2 Principe de transfert de la VoIP ........................................................................................................ 2

1.3 Les protocoles de transport de la VoIP ............................................................................................. 3

1.3.1 TCP................................................................................................................................................ 3

1.3.2 UDP ............................................................................................................................................... 3

1.3.3 RTP................................................................................................................................................ 3

1.3.4 RTCP ............................................................................................................................................. 4

1.4 Les paramètres de la VoIP ................................................................................................................. 4

1.4.1 Le délai de transmission ............................................................................................................... 4

1.4.2 Les différents échantillonnages.................................................................................................... 5

1.4.3 Optimisation de la bande passante ............................................................................................... 7

1.4.4 La gigue de phase ......................................................................................................................... 7

1.4.5 Le phénomène d’écho ................................................................................................................... 7

1.4.6 La perte de données ...................................................................................................................... 7

1.4.7 La sécurité ..................................................................................................................................... 8

1.5 Classification des approches VoIP..................................................................................................... 8

1.5.1 Le Protocole H.323 ....................................................................................................................... 8

1.5.2 Protocole SIP .............................................................................................................................. 11

1.5.3 Comparaison avec H.323............................................................................................................ 13

1.6 Conclusion ......................................................................................................................................... 15

CHAPITRE 2 : LA TECHNOLOGIE MPLS........................................................................................... 16

iii
2.1 Introduction ....................................................................................................................................... 16

2.2 L’évolution d’IP vers MPLS ............................................................................................................ 16

2.3 Principes de fonctionnement de MPLS ........................................................................................... 16

2.3.1 LSR .............................................................................................................................................. 17

2.3.2 LER ............................................................................................................................................. 17

2.3.3 Acheminement des paquets dans un réseau IP ......................................................................... 17

2.3.4 Acheminement des paquets dans un réseau MPLS ................................................................... 18

2.4 Structure fonctionnelle de MPLS .................................................................................................... 19

2.4.1 Le plan de contrôle ..................................................................................................................... 19

2.4.2 Le plan de données ..................................................................................................................... 20

2.5 Structures de données des labels...................................................................................................... 21

2.5.1 LIB............................................................................................................................................... 21

2.5.2 FIB .............................................................................................................................................. 21

2.5.3 LFIB ............................................................................................................................................ 22

2.5.4 Construction des structures de données ..................................................................................... 22

2.6 Paradigme de la commutation dans MPLS .................................................................................... 23

2.7 Les labels ............................................................................................................................................ 23

2.7.1 L'encapsulation label MPLS dans différentes technologies ..................................................... 23

2.7.2 L’en-tête MPLS ........................................................................................................................... 24

2.7.3 Pile de labels ............................................................................................................................... 24

2.8 Distribution des labels ...................................................................................................................... 25

2.8.1 Le protocole LDP ........................................................................................................................ 25

2.8.2 Le protocole CR-LDP ................................................................................................................. 25

2.8.3 Le protocole RSVP-TE ............................................................................................................... 26

2.9 Les applications de la technologie MPLS........................................................................................ 26

2.9.1 AToM........................................................................................................................................... 27

2.9.2 Le support de la qualité de service ............................................................................................. 27

2.10 Evolutions du MPLS ....................................................................................................................... 31

iv
 2.10.1 GMPLS...................................................................................................................................... 31

2.10.2 VPLS ......................................................................................................................................... 31

2.11 Sécurisation des réseaux MPLS ..................................................................................................... 31

2.11.1 La protection de Chemin .......................................................................................................... 32

2.11.2 La protection par reroutage local ............................................................................................. 33

2.11.3 La protection multi-niveaux ..................................................................................................... 33

2.12 Conclusion ....................................................................................................................................... 34

CHAPITRE 3 : DIMENSIONNEMENT DU BACKBONE MPLS ........................................................ 35

3.1 Introduction ....................................................................................................................................... 35

3.2 Dimensionnement d’un réseau offrant le service voix ................................................................... 35

3.2.1 Dimensionnement du réseau d’accès ......................................................................................... 35

3.2.2 Réseau dorsal IP/MPLS ............................................................................................................. 39

3.3 Dimensionnement pour un réseau offrant le service data ............................................................. 43

3.3.1 Etude d’un cas particulier .......................................................................................................... 44

3.3.2 Principe de distribution de charge ............................................................................................. 44

3.3.3 Capacité des liens ........................................................................................................................ 45

3.3.4 Capacité des liens supportant le trafic voix et data ................................................................... 46

3.4 Les motivations du « traffic Engineering » ..................................................................................... 46

3.4.1 Principe du « traffic Engineering » ........................................................................................... 46

3.4.2 Calcul et établissement des MPLS TE LSP ............................................................................... 48

3.4.3 Le fonctionnement de RSVP TE ................................................................................................ 49

3.5 Conclusion ......................................................................................................................................... 50

CHAPITRE 4 : SIMULATIONS ET RESULTATS ................................................................................ 51

4.1 Les outils de simulation .................................................................................................................... 51

4.1.1 OMNET ++ ................................................................................................................................. 51

4.1.2 NS-2 ............................................................................................................................................. 51

4.2 Simulation avec OPNET Modeler ................................................................................................... 51

4.2.1 Description d’OPNET................................................................................................................. 51

v
 4.2.2 Les outils d’OPNET .................................................................................................................... 52

4.2.3 Conception du réseau ................................................................................................................. 52

4.2.4 Le choix d’OPNET Modeler....................................................................................................... 55

4.3 Mise en œuvre .................................................................................................................................... 56

4.3.1 Modélisation du réseau sans la technologie MPLS................................................................... 56

4.3.2 Modélisation du réseau avec la technologie MPLS................................................................... 61

4.3.3 Les types de trafic circulant dans le Backbone .......................................................................... 63

4.3.4 Mise en œuvre du TE dans le Backbone MPLS ....................................................................... 65

4.4 Analyse des Résultats ........................................................................................................................ 68

4.4.1 Observations des trafics envoyés et reçus .................................................................................. 68

4.4.2 Comparaison de la répartition des charges................................................................................ 69

4.4.3 Impacts de la répartition des charges......................................................................................... 71

4.5 Simulation avec GNS3 ...................................................................................................................... 73

4.5.1 La topologie du réseau................................................................................................................ 74

4.5.2 Implémentation du « Traffic Engineering » avec CISCO 3600................................................ 74

4.5.3 Réalisation d’un appel entre deux IP Phones ........................................................................... 75

4.5.4 Analyse des trafics capturés avec Wireshark ............................................................................. 75

4.6 Conclusion ......................................................................................................................................... 76

CONCLUSION GENERALE .................................................................................................................... 77

ANNEXE 1 MODELE OSI ........................................................................................................................ 78
ANNEXE 2 : PROTOCOLES DE ROUTAGE ........................................................................................ 79
ANNEXE 3 DATAGRAMME IP ............................................................................................................... 80
ANNEXE 4 : CRITERE DE MOS ............................................................................................................. 83
ANNEXE 5 CONFIGURATION DES ROUTEURS AVEC GNS3 ........................................................ 84
BIBLIOGRAPHIE ...................................................................................................................................... 86
PAGE DE RENSEIGNEMENT ................................................................................................................. 88
RESUME ...................................................................................................................................................... 89
ABSTRACT ................................................................................................................................................. 89

vi
 NOTATIONS

Minuscules latines

Cycle de transmission de paquet en ms

Taille de l’enqueue du protocole de couche liaison

Taille de l’en-tête RTP/UDP/IP à ajouter en octets

Taille de l’en-tête du protocole de couche liaison en octets

Durée d’un appel de i à j
n Nombre de ressources disponibles

Majuscules latines

Capacité du lien individuel k pour le trafic data

Capacité du lien individuel pour le trafic voix

Débit par appel au niveau du site i

Débit de signalisation par appel au niveau du nœud i

Débit par appel en Kbit/s

Débit généré par le codec en Kbit/s

délai de l’émetteur

délai du réseau

temps de sauvegarde dans le buffer de gigue

temps nécessaire au codage

temps de compression

temps de décompression

vii
 Débit du lien descendant au niveau du site i

temps de mise en paquet

Débit du lien montant au niveau du site i

Première formule d’Erlang en fonction de A et n

Nombre d’appels entre le nœud i et j

Probabilité de blocage

Signalisation entre le nœud i et j

Trafic du site i au site j

Trafic entre les sites i et j

Taille de la signalisation par appel

Matrice de trafic

A Trafic offert

Minuscules grecques

coefficient de pondération attribué au chemin supportant

le trafic voix entre le site i et le site j

λ Taux d’arrivée

viii
 LISTE DES ABREVIATIONS

ACELP Algebraic Code-Excited Linear Prediction

ADSL Asymetric Digital Subscriber Line

AS Autonomous System

ASCII American Standard Code for Information Interchange

ATM Asynchronous Transmission Mode

BGP Border Gateway Protocol

CELP Code-Excited Linear Prediction

CIF Common Intermediate Format

CoS Class of Services

CR-LDP Constraint-based Routing LDP

CS-ACELP Coding Speech-Algebraic Code-Excited Linear Prediction

DiffServ Differentiated Services

DNS Domain Name System

DSPFA Dijkstra Shortest Path First Algorithm

E-LSR Egress-LSR

EXP Expérimental

FEC Forwarding Equivalent Classes

FIB Forwarding Information Base

FR Frame Relay

GMPLS Generalized Multiprotocol Label Switching

HDLC High level Data Link Control

HTTP HyperText Transfer Protocol

ix
IETF Internet Engineering Task Force

IF Interface

I-LSR Ingress-LSR

IntServ Integrated Services

IP Internet Protocol

IS-IS Intermediate System to Intermediate System

ISO International Organisation for Standardization

ISP Internet Service Provider

ISUP ISDN User Part

ITU International Telecommunication Union

LB Loopback

LD-CELP Low-Delay Code Excited Linear Prediction

LDP Label Distribution Protocol

LER Label Edge Router

LFIB Label Forwarding Information Base

LIB Label Information Base

LSP Label Switching Path

LSR Label Switching Router

MAC Medium Access Control

MCU Multipoint Control Unit

MOS Mean Opinion Score

MP-BGP Multiprotocol BGP

MPLS Multiprotocol Label Switching

MP-MLQ Multi-Pulse Maximum Likelihood Quantization

x
NS-2 Network Simulator-2

OSPF Open Shortest Path First

OTcl Object Tool Command Language

PCM Pulse Code Modulation

PHB Per Hop Behavior

PIM Protocol Independent Multicast

PE Provider Edge

PPP Point to Point Protocol

QCIF Quarter Common Intermediate Format

QoS Quality of Service

RAS Registration Admission Status

RIP Routing Information Protocol

RNIS Réseau Numérique à Integration de Services

RSVP Resource Reservation Protocol

RTCP Real Transport Control Protocol

RTP Real Transport Protocol

SB-ADPCM Sub-Band Adaptive Differential Pulse Code Modulation

SDH Synchronous Digital Hierarchy

SDP Session Description Protocol

SHIM Stanza Headers and Internet Metadata

SIP Session Initiation Protocol

SLA Service Level Agreement

SOAP Simple Object Access Protocol

SPF Short Path First

xi
SRLG Shared Risk Resource Group

Sub-QCIF Sub-Quarter Common Intermediate Format

TCP Transmission Control Protocol

TDP Tag Distribution Protocol

ToS Type of Service

UDP User Datagram Protocol

UIT-T Union Internationale des Télécommunications

URL Uniform Resource Locator

VoIP Voice over IP

VPI/VCI Virtual Path Identifier/ Virtual Channel Identifier

VPLS Virtual Private Lan Service

VRF Virtual Routing Forwarding

WDM Wavelength Division Multiplexing

WFQ Weighted Faier Queing

WSDL Web Service Description Language

XML eXtensible Markup Language

xii
 INTRODUCTION GENERALE

Le domaine de la télécommunication ne cesse d’évoluer. Les nouvelles technologies envahissent

notre quotidien ; parmi elles, on trouve la téléphonie sur IP (Internet Protocol). Cette dernière
représente une technologie récente qui s’impose rapidement dans le domaine de la communication
vocale. Elle utilise les réseaux Internet pour généraliser l’utilisation dans un nombre croissant de
foyer et d’entreprise.

Cependant, la VoIP (Voix sur IP) est encore loin de satisfaire aux exigences de qualité de service
même si de fortes améliorations sont prévisibles. En effet, sa plus grande contrainte est le délai de
bouche à oreille considéré comme acceptable par un utilisateur normal. Il devient donc
particulièrement important de savoir contrôler et caractériser la qualité de service d’un réseau IP
surtout ce délai que l’on appelle aussi temps de latence.

Notre travail consiste à faire une analyse de performance de la VoIP à travers une simulation faite
sur un Backbone qui utilise la technologie MPLS (MultiProtocol Label Switching). Cette dernière
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 ».
MPLS constitue aussi une alternative à la commutation de circuit, encore largement utilisée en
téléphonie. Ce type de commutation a comme 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 haut exigence, tel que la
voix, dans un réseau à ressources partagées, sans pour autant dégrader sa qualité.

Notre mémoire sera divisé en quatre parties, la première sera consacrée à faire une étude générale
de la VoIP. La deuxième partie fera l’objet d’une étude théorique de la technologie MPLS, suivi
du chapitre trois qui va nous présenter l’étude d’un dimensionnement du Backbone MPLS. En
dernier lieu, le chapitre quatre met en exergue une analyse sous « Opnet Modeler 14.5 » et une
implémentation sous GNS3.

1
 CHAPITRE 1 : GENERALITES SUR LA VOIP

1.1 Introduction

La voix sur IP est une technologie de communication vocale en pleine émergence. Elle fait partie
d’un tournant dans le monde de la communication. En effet, la convergence du triple play (voix,
données et vidéo) représente les enjeux principaux des acteurs de la télécommunication
d’aujourd’hui. Plus récemment, l’internet s’étend partiellement dans l’intranet de chaque
organisation, voyant le trafic total basé sur un transport réseau de paquets IP qui surpasse le trafic
traditionnel du réseau voix. [5]

Ce chapitre concerne l’aspect de la VoIP par le procédé de l’étude de son principe de transfert qui
utilise des protocoles de transport permettant d’assurer différents paramètres. Ainsi, une
classification des approches VoIP sera élaborée, suivie d’une comparaison entre le protocole
H.323 et le protocole SIP (Session Initiation Protocol).

1.2 Principe de transfert de la VoIP

La numérisation et la compression de la voix sont assurées par le codec audio de l’émetteur. Les
données numériques vont être acheminées vers le destinataire dans des paquets IP après la
suppression de silence et l’ajout des en-têtes. Ce processus est représenté par la figure 1.01. [6]

Figure 1.01 : Processus de Traitement de la Voix

2
 La numérisation
Elle consiste à convertir le signal analogique utilisant une bande de fréquence de 300 à 3400 Hz
sous forme numérique suivant le format PCM (Pulse Code Modulation) ou G.711 à 64 Kbps. En
effet, la théorie de Shannon montre que la fréquence d’échantillonnage est à 8 KHz, soit un
échantillon toutes les 125 ms. Chaque échantillon est ensuite codé sur 8 bits, ce qui donne un débit
de 64 Kbps, lequel correspond à une voix numérique non compressée.

 La compression numérique
Elle est assurée par l’utilisation des algorithmes permettant de réduire le besoin en bande passante
à des débits nettement inférieurs (16, 8 et même 4 Kbps) et d’augmenter ainsi l’efficacité du
transport de la voix. Plus le taux de compression est élevé par rapport à la référence de 64 Kbps,
moins la qualité de la voix est bonne. Toutefois, les algorithmes de compression récents
permettent d’obtenir des taux de compression élevés tout en maintenant une qualité de la voix
acceptable. L’acceptabilité par l’oreille humaine des différents algorithmes est définie selon le
critère de MOS (Mean Opinion Score).

1.3 Les protocoles de transport de la VoIP

De nombreux protocoles de couches inférieures sont concernés par le transport de la VoIP. Parmi
lesquels sont le TCP (Transmission Control Protocol), UDP (User Datagramme Protocol), RTP
(Real Time Protocol) et RTCP (Real Time Protocol Control Protocol). [2]

1.3.1 TCP

Le protocole TCP assure le bon contrôle de l’intégrité des informations transportées par le biais du
mécanisme d’accusé de réception. Il n’est pas particulièrement performant en termes de délais.

1.3.2 UDP

Il est plus simple que TCP et présente une meilleure performance moyenne par l’envoi des
paquets sans contrôle de réception (pas d’acquittement).

1.3.3 RTP

Le protocole RTP est utilisé pour le transport des flux en temps réel encapsulés dans des paquets
UDP. En effet, le transport de la voix répond à des exigences différentes de celles relatives au
transport de données.

3
1.3.4 RTCP

Le RTCP est associé à RTP afin de lui fournir les fonctionnalités de contrôle de la QoS qui lui en
manquent.

1.4 Les paramètres de la VoIP

La VoIP exige des paramètres particuliers en terme de qualité à savoir, la durée d’acheminement,
le pourcentage de perte de données. En effet, une perte de 1 % ou 2 % des données est acceptable,
en revanche, un retard de 150ms est catastrophique et rend le service inutilisable dans la
transmission de la voix. Cette dernière attend donc du transport IP l’inverse de ce qu’exigent les
données. [1]

1.4.1 Le délai de transmission

Le délai de transmission d’un paquet est défini par la formule suivante :

𝐷 = 𝐷𝐸𝑚 + 𝐷𝑅𝑒𝑠 + 𝐷𝑅𝑒𝑐 (1.01)

Avec :
𝐷𝐸𝑚 = 𝐷𝑐𝑜𝑑 + 𝐷𝑐𝑜𝑚𝑝 + 𝐷𝑝𝑎𝑞 (1.02)

𝐷𝑅𝑒𝑠 = 𝐷𝑝𝑟𝑜𝑔 + 𝐷𝑐𝑜𝑚 + 𝐷𝑎𝑡𝑡𝑒𝑛

(1.03)

𝐷𝑅𝑒𝑐 = 𝐷𝑏𝑢𝑓𝑓 + 𝐷𝑑𝑒𝑝𝑎𝑞 + 𝐷𝑑𝑒𝑐𝑜𝑚𝑝 (1.04)

Où :
 le délai de l’émetteur
 : le temps nécessaire au codage
 : le temps de compression

 : le temps de mise en paquet

 : le délai du réseau
 : le temps de propagation

 : le temps de commutation
 : le temps de mise en file d’attente

4
 : le délai du récepteur
 : le temps de sauvegarde dans le buffer de gigue

 : le temps de dépaquetisation

 : le temps de décompression

Le délai de transmission doit être inférieur à 150 ms pour une meilleure interactivité selon la
recommandation G.114 de l’UIT-T.

Bon Moyen Mauvais

Délai de transit D<150 ms 150 ms <D< 400ms D >400ms

Gigue de phase G<20 ms 20 ms <G< 50ms G> 50 ms

Perte de données P< 1% 1% <P< 3% P >3%

Tableau 1.01: Recommandation G.114 de l’UIT-T

1.4.2 Les différents échantillonnages

Le codec ou paramètre d’échantillonnage est structuré en VoIP. Il détermine non seulement à

quelle vitesse la voix sera échantillonnée et dimensionnée mais aussi le flux de données
numériques que va générer la transformation d’un échantillon temporel de voix analogique. Les
codecs sont répertoriés par leur nom à l'ITU.

1.4.2.1 Les codecs audio

 G.711 : il utilise le codage PCM qui est une technique de compression de base. En effet, il
correspond à un codage sur 8 bits pour un débit de 64Kbits/s. Il permet de fournir une très
bonne qualité de restitution de la voix au détriment d’une consommation de bande passante
élevée.

 G.729 : il encode, compresse le signal vocal en 8 Kbit/s et fournit un taux de compression

moyen. La qualité de restitution de la voix est donc de qualité moyenne.

5
 G.722 : le codage donne un débit de 64, 56 ou 48 Kbits/s avec une fréquence
d’échantillonnage de 16000 Hz. Ainsi, il apporte une qualité supérieure par rapport à celles des
codecs précédents.

 G.728 : il fournit un débit de 16 Kbit/s avec une fréquence d’échantillonnage à 8000 Hz.
L’avantage est le délai, nettement plus faible que CELP (Code-Excited Linear Prediction), qui
est de l’ordre de 2 ms.
Le tableau 1.02 résume la variété de codec audio suivant la norme H.323 :

Codec Codage Bande Fréquence Vitesse Complexité

passante d’échantillonnage (Kbit/s)
du signal (Hertz)
(Hertz)
G.711 PCM 300-3400 8000 64 basse

G.722 SB-ADPCM 300-3400 16000 48 moyenne

56
64

G.723 ACELP 300-3400 8000 5.3 haute

MP-MLQ 6.4

G.728 LD-CELP 300-3400 8000 16 basse

G.729 CS-ACELP 300-3400 8000 8 haute

13

Tableau 1.02: Codecs Audio

1.4.2.2 Codecs vidéo

Il existe plusieurs types de codecs vidéo à savoir :

 H.261 : cette recommandation a été déposée en mars 1993 pour permettre une interopérabilité
des services audiovisuels. Elle a été prévue à l’origine pour fonctionner sur les lignes RNIS
(Réseau Numérique à Integration de Services). Elle supporte deux résolutions : CIF (Common

6
 Intermediate Format) qui donne un débit de 15 images / secondes avec une taille de trame de
288 lignes X 352 pixels et la résolution QCIF (Quarter Common Intermediate Format) qui
donne un débit de 30 images/seconde avec une taille de trame de 144 lignes X 176 pixels.

 H.263 : il a été conçu au départ, pour assurer des débits inférieurs à 64 kbit/s. Maintenant, il
permet des débits supérieurs. Il supporte cinq résolutions : sub-QCIF de taille de trame 128X
92, QCIF de taille de trame 176X144, CIF (288 lignes X 352), 4CIF (702 X 576), 16CIF
(1408 X 1152).

 MPEG-4 : ce codec est un successeur des formats MPEG-1 et MPEG-2. Il permet de

compresser des fichiers audio et vidéo volumineux et de réduire la taille des fichiers de 33 % à
50 % avec plus de puissance du processeur.

1.4.3 Optimisation de la bande passante

Pour un bon partage de la bande passante, il faut connaître l'ensemble des flux pouvant avoir une
influence importante sur le transport de la voix.

1.4.4 La gigue de phase

La gigue est la variation du délai de transmission due à une charge ponctuelle dans le réseau. Pour
résoudre cette variation, on peut utiliser le buffer de gigue. Néanmoins, son utilisation peut se
traduire par un délai et une perte de paquet supplémentaire si ce dernier arrive après le délai
maximum autorisé par le buffer.

1.4.5 Le phénomène d’écho

C'est le délai entre l'émission du signal et la réception de ce même signal en réflexion.

Cet écho est causé par les composants électroniques des parties analogiques.

1.4.6 La perte de données

La transmission de la voix par paquets s'appuie sur le protocole RTP. Ce dernier permet de
transmettre sur IP les paquets de voix en reconstituant les informations même si la couche de

7
transport change l'ordre des paquets. Il utilise pour cela des numéros de séquence et s'appuie sur
UDP. Les contraintes temps réel de délai de transit rendent inutile la retransmission des paquets
perdus : même retransmis, un datagramme RTP arriverait tard pour être utile dans le processus de
reconstitution de la voix. En voix sur IP, on ne retransmet pas les données perdues car leurs
transmissions doivent s'effectuer en temps réel.

Ces pertes de données VoIP sont dues aux congestions sur le réseau y entraînant des rejets de
paquets, ou à une gigue excessive provoquant des rejets de paquets dans les buffers de gigue du
récepteur. Ceux-ci ne peuvent pas accueillir tous les paquets arrivés tard.

1.4.7 La sécurité

Tous les postes téléphoniques deviennent accessibles de l'extérieur, soit par écoute de la
conversion, soit par déni de service etc., alors il n'y a aucune importance si l'information est
transmise ou non du moment qu'elle sera attaquée.

1.5 Classification des approches VoIP

Deux approches existent aujourd'hui pour apporter des services de VoIP, et plus généralement des
services multimédia sur IP. La première approche, définie par l'lTU-T est décrite dans les
recommandations H.323 (pour les terminaux situés dans un réseau d'entreprise) et H.324 (pour les
terminaux connectés sur une liaison modem, ou encore la visiophonie 3G (3ème génération)). La
deuxième approche, définie par l'IETF (Internet Engineering Take Force) s'appuie sur le protocole
SIP (Session Initiation Protocol). [6]

1.5.1 Le Protocole H.323

H.323 est le prolongement logique des différents protocoles de signalisation issus du monde
téléphonique dans un contexte IP. Plusieurs protocoles du RNIS ont été adaptés pour H.323
(procédures d'appel multimédia, conférences d'appel, services supplémentaires). Comme pour le
réseau téléphonique, H.323 définit une architecture basée sur une typologie précise orientée
équipement. Chaque équipement a une fonction particulière décrite dans le standard H.323 ou
dans l'un des standards associés. Par ailleurs, de nouveaux protocoles ont été définis pour les
procédures d'authentification, d’enregistrement et de localisation des utilisateurs.

8
1.5.1.1 Les composantes d’un système H.323

L'architecture standard H.323 est composée des différents éléments suivants :

 Terminal :
Suivant les différentes architectures connues d’un réseau VoIP, le terminal peut être une station de
travail ou tout autre moyen de communication supportant la pile réseau H.323.

 Gateway (passerelle) :
Le Gateway est un élément de routage équipé des cartes d'interfaces analogiques et/ou numériques
pour s'interconnecter avec d'autres PABX ou des opérateurs de télécommunications locaux,
nationaux ou internationaux. Plusieurs passerelles peuvent faire partie d'un seul et même réseau,
ou l'on peut également avoir une passerelle par réseau local (LAN). La passerelle peut également
assurer l'interface de postes analogiques classiques qui pourront utiliser toutes les ressources du
réseau téléphonique IP (appels internes et externes, entrants et sortants).

 MCU (Multipoint Control Unit)

Le MCU est un élément optionnel et gère les conférences audio vidéo.

 Gatekeeper (garde-barrière) :
C’est un élément fonctionnel distinct de la passerelle, mais qui est souvent mis en œuvre sur la
même plate-forme matérielle. L’ensemble des éléments (terminaux ou passerelles) gérés par un
« Gatekeeper » est appelé « zone ». Un « Gatekeeper » fournit essentiellement trois types de
services :
 la translation d’adresse entre les alias des terminaux et leur adresse. Les alias peuvent être
de type E.164 (numéro de téléphone) ou un identifiant tel qu’un nom de machine ou une
adresse e-mail.
 le contrôle de la bande passante par la limitation du nombre de connexions simultanées ou
du maximum de bandes passantes utilisables. Quand ce seuil est dépassé, le Gatekeeper
refuse toute nouvelle connexion.
 le contrôle d’admission illustré par le rejet des appels non autorisés.

9
 Figure 1.02 : Architecture Standard H.323

1.5.1.2 La pile protocolaire suivant H.323

H.323 s’appuie sur trois familles de protocoles à savoir :

 Les protocoles de communications (RTP, RTCP, etc.) ;
 Les protocoles de codages audio et vidéo ;
 Les protocoles de signalisations (RAS, H.245, Q931).

Ces signalisations se basent sur le protocole de couche 4 : TCP. Chacun de ces protocoles joue un
rôle primordial lors de l'établissement d'une communication téléphonique sur IP.
 Q.931 : établit la communication
 RAS : enregistre les équipements terminaux et contrôle l'admission de la communication.
 H.245 : contrôle l'ouverture et la fermeture des canaux pour les médias ainsi que la négociation
des formats des données transmises.
 H.255.0 : sert pour la synchronisation entre terminaux.
 H.225 : il est utilisé pour une connexion entre deux points de terminaison.

10
La figure 1.03 nous montre l’architecture de ces protocoles:

Figure 1.03 : La pile de protocole selon H.323

1.5.2 Protocole SIP

Le protocole SIP (Session Initiation Protocol) est un protocole de plus en plus utilisé actuellement
dans le monde de la voix sur IP. Il s'agit d'un protocole de signalisation utilisé pour ouvrir,
modifier et fermer des sessions dans un environnement IP. Une session peut tout simplement être
soit un appel téléphonique (en réception et en émission) soit une mise en relation entre plusieurs
supports multimédia au même instant (conférence). [7]

1.5.2.1 Rôle et fonctionnalités du protocole SIP

Les rôles du SIP consistent à :

 Réutiliser les bases des protocoles existants. Par exemple, SIP ayant été créé bien après http,
utilise les URL pour l'adressage.

 Pouvoir associer ses fonctions aux protocoles existants et aux applications tels que les
navigateurs Web.

11
 Permettre aux personnes disposant d'une adresse SIP d'être constamment joignable quelque
soit l'endroit où elles se trouvent. Une adresse ou un numéro SIP suivra la personne lorsqu'elle
se déplacera d'un lieu à un autre.
Les 4 fonctionnalités principales du SIP :
 Permet l'allocation du nom d'un utilisateur à son adresse au sein d'un réseau.
 Permet la gestion des appels : ajouter, supprimer ou transférer un participant à une session.
 Permet de modifier les caractéristiques d'une session pendant que celle-ci est déjà ouverte.
 Peut fonctionner avec HTTP (HyperText Transfer Protocol), SOAP (Simple Object Access
Protocol), XML (eXtensible Markup Language), WSDL (Web Service Description Language),
SDP (Session Description Protocol) et bien d'autres.

1.5.2.2 Les composants d’un système SIP

Figure 1.04 : Architecture du protocole SIP

L'architecture standard SIP se compose des éléments suivants :

 Terminal (Phone, Messenger, etc.);
 Serveur de localisation ;
 Serveur d'enregistrement ;
 Serveur de redirection ;
 Proxy ;
 Gateway.

12
1.5.2.3 La pile protocolaire SIP

Pour assurer le transfert du flux média, le protocole SIP utilise d'autres protocoles tels que :

 RSVP (Resource Reservation Protocol) : Ce protocole réserve les ressources réseaux sur IP
avec une excellente qualité de service.

 RTP : Il transporte des informations en temps réel avec une excellente qualité de services.

 RTCP : Il assure le contrôle de flux des données multimédia.

 SDP : Ce protocole assure la description des sessions multimédia.

La pile protocolaire SIP est représentée par la figure 1.05 :

Figure 1.05 : Pile protocolaire selon SIP

1.5.3 Comparaison avec H.323

Voici les avantages du protocole H.323 :

 Il existe de nombreux produits utilisant ce standard adopté par de grandes entreprises telles
que Cisco, IBM, Intel, Microsoft, Netscape, etc.

13
 Les cinq principaux logiciels de visioconférence Picturel 550, Proshare 500, Trinicon 500,
Smartstation et Cruiser 150 utilisent sur IP la norme H.323.
 Un niveau d’interopérabilité très élevé, ce qui permet à plusieurs utilisateurs d'échanger des
données audio et vidéo sans faire attention aux types de média qu'ils utilisent.

Voici les avantages du protocole SIP :

 SIP est un protocole plus rapide. La séparation entre ses champs d’en-tête et son corps du
message facilite le traitement des messages et diminue leur temps de transition dans le réseau.
 Le nombre des en-têtes est limité (36 au maximum et en pratique, moins d'une dizaine d'en-
têtes sont utilisées simultanément), ce qui allège l'écriture et la lecture des requêtes et
réponses.
 SIP est un protocole indépendant de la couche transport. Il peut être utilisé tant avec TCP
qu’avec UDP.
 De plus, il sépare les flux de données de ceux de la signalisation, ce qui rend plus souple
l'évolution en direct d'une communication (arrivée d'un nouveau participant, changement de
paramètres…).

SIP H.323

Nombre d’échanges pour 1 à 5 allers-retours 6 à 7 allers-retours

établir la connexion
Maintenance du code Simple par sa nature textuelle Complexe et nécessitant un
protocolaire à l’exemple de Http compilateur

Evolution du protocole Protocole ouvert à des Ajout d’extensions

nouvelles fonctions propriétaires sans
concertation entre vendeurs
Fonction de télé services Oui, par défaut H.323 v2 + H.450

Détection d’un appel en Oui Inexistante sur la version 1:

boucle un appel route sur l’appelant
provoque une infinité de
requêtes
Signalisation multicast Oui, par défaut Non

Tableau 1.03: Comparaison entre SIP et H.323

14
1.6 Conclusion

La qualité de service n’a pas été réellement prise au sérieux lors de la conception initiale des
réseaux IP. Le protocole IP, comme la majorité des autres technologies de transport de données en
mode paquet, a été construit et optimisé pour transporter des fichiers de données, et non pas la
voix ou la vidéo. Il est probable que dans l’avenir, la recherche sera consacrée principalement à
dépasser la qualité vocale des réseaux téléphoniques actuels (en utilisant des codeurs bande élargie
en voix sur IP, ou encore de codeurs stéréo ou spatialisés), et à améliorer la qualité de la voix sur
IP.
En résumé, les principaux paramètres qui caractérisent la QoS d’un réseau transportant la voix en
mode paquet sont :
 l’écho ;
 la capacité (bande passante) ;
 le délai de transmission de bout en bout (latence) ;
 la variation de ce délai (gigue) ;
 le taux de perte de paquets ;
 le taux de déséquencement de paquets.

Une solution, qui pourra nous aider à avoir une bonne qualité de service, est l’amélioration au
niveau du passage des paquets dans le réseau IP (routage dynamique avec gestion de files
d’attente, et des techniques de contrôle de flux et contrôle de congestion). Dans le chapitre suivant
nous élaborons la technologie MPLS qui permet d’améliorer l’efficacité du routage et d’enrichir
les services de routages.

15
 CHAPITRE 2 : LA TECHNOLOGIE MPLS

2.1 Introduction

MPLS est une technique réseau en cours de normalisation à l’IETF. Son rôle principal est de
combiner les concepts de routage IP niveau 3 et les mécanismes de la commutation niveau 2
implémentée dans ATM (Asynchronous Transmission Mode) ou Frame Relay. Au début, il avait
pour but de commuter plus rapidement le trafic IP en ajoutant des labels aux paquets afin
d’accélérer les traitements dans les commutateurs. Aujourd’hui, avec l’arrivée des commutateurs
capables de traiter les en-têtes IP, MPLS ne réside plus dans sa rapidité d’effectuer les traitements.
Il est désormais utilisé comme un outil d’ingénierie de trafic dans les réseaux dorsaux IP.

Dans ce chapitre, nous allons voir l’évolution d’IP vers MPLS, ses principes de fonctionnement,
ses applications, ses évolutions et enfin, les différentes techniques de sécurisation.

2.2 L’évolution d’IP vers MPLS

Au milieu des années 90, il y a eu une augmentation importante de la taille des réseaux, du trafic
et de l’apparition de nouveaux besoins comme les applications multimédia. Pour transporter les
paquets à travers un réseau IP, les routeurs analysent l’adresse de destination dans l’en-tête avant
de les envoyer vers la bonne interface de sortie. Ce processus s’appelle le routage IP et il est
réitéré chaque fois que les paquets arrivent sur un routeur. Un réseau IP fonctionne dans un mode
non connecté, car les paquets constituant un message peuvent emprunter des chemins. Le
processus de routage prend beaucoup de temps et consomme énormément de ressources au niveau
du routeur. A ce titre, il est nécessaire de trouver une méthode plus efficace pour le routage des
paquets. C’est la nouvelle technologie appelée MPLS qui a été mise au point. Son principe de base
est de reprendre les avantages du routage IP et ceux de la commutation afin de répondre aux
besoins de fiabilité et de disponibilité.

2.3 Principes de fonctionnement de MPLS

Un réseau MPLS est formé de deux types de routeurs à savoir, le LSR et le LER. [9]

16
2.3.1 LSR

Le LSR (Label Switch Router) est un routeur de cœur du réseau qui effectue la commutation sur
les labels. Il participe à la mise en place du chemin par lequel les paquets sont acheminés.
Lorsqu’il reçoit un paquet labélisé, il le permute avec un autre label de sortie et expédie le
nouveau paquet labélisé sur l'interface de sortie appropriée. Le LSR peut jouer plusieurs rôles à
savoir :
 l'échange d'informations de routage
 l'échange des labels
 l'acheminement des paquets

2.3.2 LER

Le LER (Label Edge Router) 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 traditionnel. Les deux types de LER sont :
 Ingress LER : gère le trafic qui entre dans un réseau MPLS.
 Egress LER : gère le trafic qui sort d'un réseau MPLS.

Figure 2.01 : Exemple d’un réseau MPLS

2.3.3 Acheminement des paquets dans un réseau IP

Dans un réseau IP classique, il y a une mise en œuvre 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

17
protocole de routage, chaque nœud aura une vision plus ou moins complète du réseau et pourra
calculer une table de routage contenant l'ensemble des destinations. Chaque destination sera
associée à un "prochain saut" ou "Next Hop". Le routage IP classique distingue les paquets en se
basant seulement sur les adresses réseaux de destination. [8]

2.3.4 Acheminement des paquets dans un réseau MPLS

La mise en œuvre de MPLS se repose sur la détermination des 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 FEC (Forwarding Equivalence Class). Une FEC est la
représentation d'un ensemble de paquets. Ces derniers suivent le même chemin et ont la même
priorité. 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. 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 2.01, la flèche en bleue). A 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 LSP (Label Switched Path).

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 paquets appartenant à la même FEC subiront
une commutation simple à travers le chemin découvert.

Pour que les LSR puissent commuter correctement les paquets, l’« Ingress LER » affecte un label
à ces paquets. Cette opération s’appelle « label imposition » ou « label pushing ». Si on prend
l'exemple de la figure 2.01 :
Le LSR1 saura en consultant sa table de commutation que tout paquet entrant ayant le label L=18
appartient à telle FEC et donc doit être commuté sur telle sortie en lui attribuant un nouveau label
L=21. Ce processus s’appelle « label swapping ». Ce dernier sera exécuté par tous les LSR du LSP
jusqu'à l’« Egress LER ». Enfin, le LER supprimera le label et routera le paquet de nouveau dans
le monde IP de façon traditionnelle. Cette opération s’appelle « label popping » ou « label
disposition ».

18
L'acheminement des paquets dans le domaine MPLS ne se fait pas à base d'adresse IP mais de
label. Il est clair qu'après la découverte du chemin (par le protocole de routage), il faut mettre en
œuvre un protocole qui permet de distribuer les labels entre les LSR. Ces derniers constituent leurs
tables de commutation adéquate à chaque paquet entrant. Cette tâche est effectuée par un
protocole de distribution de label, tel que LDP (Label Distribution Protocol) ou RSVP TE
(Resource Reservation Protocol Traffic Engineering).

Les opérations « label pushing » et « label 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 « label
swapping » en consultant la table de commutation. [13]

2.4 Structure fonctionnelle de MPLS

Le protocole MPLS est fondé sur les deux plans principaux :

2.4.1 Le plan de contrôle

Le plan de contrôle est composé d’un ensemble de protocoles de routage classique et des
protocoles de signalisation. Il est chargé de la construction du maintien et de la distribution des
tables de routage et des tables de commutations. Pour ce faire, le plan de contrôle utilise des
protocoles de routages classiques, tels qu’IS-IS (Intermediate System to Intermediate System) ou
OSPF afin de créer la topologie des nœuds. Les protocoles de signalisations sont spécialement
développés pour le réseau MPLS comme LDP, MP-BGP (Multiprotocol Border Gateway
Protocol) ou RSVP.

Dans un réseau MPLS, il existe deux méthodes pour créer et pour distribuer les labels. Ces
méthodes sont « Implicit routing » et « Explicit routing ». Ces deux méthodes sont celles utilisées
pour définir les LSP. La méthode « Implicit routing » est celle du routage implicite, saut par saut
(hop by hop), où chaque paquet contenant un LSP choisit indépendamment le saut suivant pour
une FEC. Le routage explicite est la méthode « Explicit routing » où le premier routeur I-LSR
détermine la liste des nœuds ou des routeurs LSR à suivre pour délivrer le paquet. [13]

19
2.4.2 Le plan de données

Le plan de données permet de transporter les paquets labélisés à travers le réseau MPLS en se
basant sur les tables de commutations. Il correspond à l’acheminement des données en accolant un
en-tête SHIM (Stanza Headers and Internet Metadata) aux paquets arrivant dans le domaine
MPLS. Le plan de données est indépendant des algorithmes de routages et d'échanges de Label. Il
utilise une table de commutation appelée LFIB (Label Forwarding Information Base) pour
transférer les paquets labélisés avec les bons labels. Cette table est remplie par les protocoles
d'échange de label comme le protocole LDP.

A partir des informations de labels apprises par le protocole LDP, les routeurs LSR construisent
deux tables telles que la LIB (Label Information Base) et la LFIB. D’une manière générale, la LIB
contient tous les labels appris des voisins LSR, tandis que la LFIB est utilisée pour la
commutation proprement dite des paquets labélisés. La table LFIB est un sous-ensemble de la
base LIB. [9]

Figure 2.02 : Architecture d’un routeur Edge LSR

20
Exemple :
 Réception du label 17 pour les paquets à destination du 10.0.0.0/8
 Génération d'un label 24 pour ces paquets et expédition de l'information aux autres
routeurs
 Insertion de l'information dans la LFIB

Figure 2.03 : Structure fonctionnelle du routeur

2.5 Structures de données des labels

Le protocole MPLS utilise les trois structures de données LIB, LFIB et FIB pour acheminer les
paquets. [9]

2.5.1 LIB

La première table construite par le routeur MPLS est la table LIB qui est la base de données
utilisée par LDP. Elle contient pour chaque sous-réseau IP la liste des labels affectés par les LSR
voisins. Il est possible de connaître les labels affectés à un sous-réseau par chaque LSR voisin et
elle contient tous les chemins possibles pour atteindre la destination.

2.5.2 FIB

Le FIB (Forwarding Information Base) constitue la base de données utilisée pour acheminer les
paquets non labélisés (routage IP classique). Un paquet à acheminer est labélisé si le label du saut
suivant est valable pour le réseau de destination IP.

21
2.5.3 LFIB

A partir de la table LIB et de la table de routage IP du réseau interne au Backbone, chaque routeur
LSR construit une table LFIB. Cette dernière sera utilisée pour commuter les paquets labélisés.
Dans le réseau MPLS, chaque sous-réseau IP est appris par un protocole IGP qui détermine le
prochain saut pour l’atteindre. Donc, pour atteindre un sous-réseau IP donné, le routeur LSR
choisit le label d’entrée de la table LIB qui correspond à ce sous-réseau IP, et sélectionne comme
label de sortie le label annoncé par le routeur voisin déterminé par le protocole IGP.

2.5.4 Construction des structures de données

La construction des structures de données effectuées par chaque routeur LSR doit suivre les étapes
suivantes : [13]
 Élaboration des tables de routages par les protocoles de routage.
 Allocation indépendamment d'un label à chaque destination dans sa table de routage par le
LSR.
 Enregistrement dans la table LIB des labels alloués ayant une signification locale.
 Enregistrement dans la table LFIB de l'action à effectuer par ces labels et de leur prochain
saut.
 Envoi par le LSR des informations sur sa table LIB à ses voisins.
 Enregistrement par chaque LSR des informations reçues dans sa table LIB.
 Enregistrement des informations reçues des prochains sauts dans la table FIB.

Figure 2.04 : Utilisation des structures de données pour l’acheminement

22
2.6 Paradigme de la commutation dans MPLS

Un LSR peut effectuer l'un des trois scénarii d'acheminement d'un paquet suivants :
 Le paquet arrivant à l'entrée du domaine MPLS ne contient que des adresses IP.
L'acheminement est basé sur la table FIB en ajoutant un Label « Push ».
 Le paquet arrivant à la sortie du domaine MPLS ne contient que des adresses IP.
L'acheminement est basé sur la FIB sans l'utilisation d'un label.
 Le paquet arrivant contient un label, dans ce cas l'acheminement sera basé sur la table
LFIB et le label sera échangé (Swapping). [9]

2.7 Les labels

2.7.1 L'encapsulation label MPLS dans différentes technologies

Le protocole MPLS, basé sur le paradigme de changement de label, dérive directement de

l'expérience acquise avec l'ATM. Ce mécanisme est similaire à celui de Frame Relay ou des
liaisons PPP (Point to Point Protocol). L'idée de MPLS est de rajouter un label de couche 2 aux
paquets IP dans les routeurs frontières d'entrée du réseau.

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 2.05 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.).D’où son nom de "MultiProtocol
Label Switching". [13]

Figure 2.05 : L’encapsulation MPLS dans différentes technologies

23
2.7.2 L’en-tête MPLS

L'en-tête MPLS se situe entre les en-têtes des couches 2 et 3, où l'en-tête de la couche 2 est celui
du protocole de liaison et la couche 3 est l'en-tête IP. L'en-tête est composé de quatre champs :
 Le champ Label (20 bits), valeur représentant le label, fournit les informations sur le
protocole de la couche 2 et d’autres informations pour transférer les données.
 Le champ Exp ou CoS (3 bits) pour la classe de service (Class of Service).
 Un bit Stack pour supporter un label hiérarchique (empilement de labels).
 Un champ TTL (Time To Live) pour limiter la durée de vie du paquet (8 bits). Ce champ
TTL est le même que pour IP.

Figure 2.06 : En-tête MPLS

2.7.3 Pile de labels

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 dans le réseau.
Les LSR de frontière de réseau auront la responsabilité de pousser ou tirer la pile de labels pour
désigner le niveau d'utilisation courant.
Les applications suivantes l’exigent :
 MPLS VPN (MPLS Virtual Private Network): MP-BGP est utilisé pour propager un label
secondaire en addition à celui propagé par TDP (Tag Distribution Protocol) ou LDP.
 MPLS TE : utilise RSVP TE pour établir un tunnel LSP. RSVP TE propage aussi un label
en addition à celui propagé par TDP ou LDP.

24
 Figure 2.07 : Pile de labels

2.8 Distribution des labels

2.8.1 Le protocole LDP

Le protocole LDP est un protocole de signalisation (plus précisément, de distribution des labels)
héritier du protocole propriétaire TDP (Tag Distribution Protocol). Pour décrire le
fonctionnement, rappelons la notion de l'arbre de plus court chemin : pour un préfixe d'adresse, le
protocole de routage classique définit implicitement un arbre de plus court chemin, arbre ayant
pour racine le LSR de sortie (celui qui a annoncé le préfixe) et pour feuilles les différents routeurs
d'entrée. Le routeur de sortie va annoncer le préfixe à ses voisins, tout y en associant un label. Les
messages de signalisation vont « monter » jusqu'aux routeurs d'entrée, permettant à chaque LSR
intermédiaire d'associer un label au préfixe.

2.8.2 Le protocole CR-LDP

CR-LDP est une version étendue de LDP, où CR correspond à la notion de « routage basé sur les
contraintes des LSP ». Tout comme LDP, CR-LDP utilise des sessions TCP entre les LSR, au
cours desquelles il envoie les messages de distribution des étiquettes. Ceci permet en particulier à
CR-LDP d’assurer une distribution fiable des messages de contrôle.
Les échanges d’informations nécessaires à l’établissement des LSP utilisant CR-LDP sont décrits
dans la figure 2.08. [13]

Figure 2.08 : Etablissement d’un LSP par CR-LDP

25
2.8.3 Le protocole RSVP-TE

Le protocole RSVP utilisait initialement un échange de messages pour réserver les ressources des
flux IP à travers un réseau. Une version étendue de ce protocole RSVP-TE, en particulier pour
permettre les tunnels de LSP, autorise actuellement RSVP à être utilisé pour distribuer des
étiquettes MPLS.
RSVP est un protocole complètement séparé de la couche IP, qui utilise des datagrammes IP ou
UDP pour communiquer entre LSR. RSVP ne requiert pas la maintenance nécessaire aux
connexions TCP, mais doit néanmoins être capable de faire face à la perte de messages de
contrôle.
Les échanges d’informations nécessaires à l’établissement des tunnels LSP utilisant RSVP sont
décrits dans la figure 2.09.

Figure 2.09 : Etablissement LSP par RSVP-TE

2.9 Les applications de la technologie MPLS

La motivation primaire de MPLS était d'accroître la vitesse de traitement des paquets au niveau
des nœuds intermédiaires. Les routeurs actuels sont équipés par des circuits et par des algorithmes
permettant un acheminement 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 ses applications qui
étaient très difficiles voire impossibles à mettre en œuvre avec IP traditionnel. L'implémentation
sera différente en fonction des objectifs recherchés. Cela se traduit principalement par une façon

26
différente d'assigner et de distribuer les labels. Le principe d'acheminement des paquets fondé sur
l'exploitation des labels étant le mécanisme commun à toutes les approches.
Les principales applications de MPLS concernent :
 Any Transport over MPLS (AToM).
 Le support des réseaux privés virtuels (MPLS VPN).
 Le support de la qualité de service (MPLS QoS).
 Le « Traffic Engineering » (MPLS TE).

2.9.1 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 tels que Frame Relay, Ethernet, PPP
et ATM. [10]

2.9.2 Le support de la qualité de service

Avec la technologie MPLS, la QoS est un élément crucial pour un réseau d'opérateur. En effet,
l’opérateur doit pouvoir garantir à ses clients le transport de leurs flux en garantissant différentes
contraintes. La qualité de service se décline principalement en quatre paramètres : débit, délai,
gigue et perte. [11]
Le support de la QoS peut être mise en œuvre de deux façons sur MPLS :
 Diffserv (Differentiated Services) : 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.
 L'utilisation du « Traffic Engineering ».

2.9.2.1 La différentiation des services

Le modèle de différenciation des services semble être plus adéquat pour les réseaux multiservices
tels que l’Internet. Ce modèle signifie en d’autres termes donner la priorité à une classe de service
au dépens d’une autre au moment de congestion. Le modèle DiffServ définit une approche
totalement différente en comparaison avec le modèle IntServ. Il ne nécessite ni une réservation de
bout en bout ni une signalisation. Il permet d’affecter chaque paquet à une classe de service. La
complexité est reléguée dans les extrémités du réseau. Les services différenciés de l'architecture
DiffServ permettent de diminuer substantiellement les informations d’état que chaque nœud du
réseau doit mémoriser. [12]

27
Dans l’architecture DiffServ, le traitement différencié des paquets s’appuie sur 3 opérations
fondamentales :
 la classification des flux en classes de service.

 l’introduction de priorités au sein des classes (Scheduling).

 la gestion du trafic dans une classe donnée (Queue management).

Figure 2.10 : Classification, marquage et conditionnement du trafic dans le domaine DiffServ

Cette architecture convient à des réseaux pour lesquels il n'est pas raisonnable d'envisager une
signalisation flux par flux. Elle ne considère donc que des agrégats de flux pour lesquels une
signalisation avec réservation de ressources peut être envisagée.
En fait, un routeur de cœur ne conserve pas d'état pour un flux ou un agrégat donné, mais traite
tous les paquets d'une classe donnée de la même manière. Les données sont identifiées grâce à un
marquage dans le champ ToS (Type of Service, champ spécifique réservé dans l'en-tête IP de 8
bits), qui fixe les priorités.

Au contraire du modèle Intserv (Integrated Services) qui traite indépendamment chaque flot, les
routeurs DiffServ traitent les paquets en fonction de la classe codée dans l'en-tête IP selon un
comportement spécifique : le PHB (Per Hop Behaviour).
Chaque ensemble de paquets défini par une classe reçoit alors un même traitement et chaque
classe est codée par un DSCP (DiffServ Code Point). Un PHB est défini par les priorités qu’il a
sur les ressources par rapport à d’autres PHB.

28
Diffserv définit quatre PHB ou classes de service :
 Best Effort
 Expedited Forwarding (EF)
 Assured Forwarding (AF)
 Default Forwarding (DF)

Figure 2.11 : Insertion du champ DSCP

Cette notion de PHB permet de construire une variété de services différenciés. Les PHB sont mis
en œuvre par les constructeurs dans les routeurs en utilisant des mécanismes de gestion de files
d'attente (Custom Queuing, Weighted Fair Queuing, etc.) et de régulation de flux.

a) Best Effort

PHB par défaut et dont le DSCP vaut 000000. Le principe du Best Effort se traduit par une
simplification à l’extrême des équipements d’interconnexion. Quand la mémoire d’un routeur est
saturée, les paquets sont rejetés. Les principaux inconvénients de cette politique de contrôle de
flux sont un trafic en dents de scie composé de phases où le débit augmente puis se réduit
brutalement et une absence de garantie à long terme.

29
 b) Expedited Forwarding

La classe Expedited Forwarding correspond à la valeur 101110 pour le DSCP. L’objectif est de
fournir un service de transfert équivalent à une ligne virtuelle dédiée à travers le réseau d’un
opérateur.
Le contrat porte sur un débit constant. Les paquets excédentaires sont lissés ou rejetés à l’entrée
pour toujours rester conforme au contrat. L’opérateur s’engage à traiter ce trafic prioritairement.
Pour que le service soit performant, il faut qu’il ne présente qu’une faible partie du trafic total,
qu’aucun paquet marqué EF ne soit rejeté dans le cœur du réseau.
Pour atteindre ces performances, les paquets d’un service EF ne doivent pas subir de file d’attente
ou passer par des files de très petite taille et strictement prioritaires.

c) Assured Forwarding

Le PHB AF fournit des niveaux de garantie d’acheminement des paquets. Il est constitué d’un
ensemble de 4 classes de service ayant chacune 3 niveaux de rejet de paquets différents.
 (04) quatre classes de service (Il n’y a pas de priorité parmi ces classes)
 (03) priorités définissant l’ordre de rejet dans un routeur en cas de congestion.

Figure 2.12 : Ensemble des classes du PHB AF

Par exemple, en cas de congestion dans la classe de service 4, les paquets de valeur DSCP 100110
seront rejetés en premier lieu.
Les classes sont donc choisies par l'utilisateur et restent les mêmes tout au long du trajet dans le
réseau. Tous les paquets d’un même flux appartiennent à la même classe.
A l’intérieur de chaque classe, un algorithme de rejet sélectif différencie entre 3 niveaux de
priorité. En cas de congestion dans une des classes AF, les paquets de basse priorité sont rejetés en

30
premier. La priorité peut être modifiée dans le réseau par les opérateurs en fonction du respect ou
non des contrats.
AF offre différents niveaux de services :
 AF1 (AF11, AF12, AF13)
 AF2 (AF21, AF22, AF23)
 AF3 (AF31, AF32, AF33)
 AF4 (AF41, AF42, AF43)

2.10 Evolutions du MPLS

2.10.1 GMPLS

Une première extension du MPLS est le Generalized MPLS. Le concept de cette dernière est
d’étendre la commutation aux réseaux optiques. Le label, en plus de pouvoir être une valeur
numérique, peut alors être mappé par une fibre. Le GMPLS met en place une hiérarchie dans les
différents supports de réseaux optiques. Il permet de transporter les données sur un ensemble de
réseaux hétérogènes en encapsulant les paquets successivement à chaque entrée dans un nouveau
type de réseau. Ainsi, il est possible d'avoir plusieurs niveaux d'encapsulations selon le nombre de
réseaux traversés, le label correspondant étant conservé jusqu'à la sortie du réseau. GMPLS
reprend le plan de contrôle de MPLS en l'étendant pour prendre en compte les contraintes liées
aux réseaux optiques. En effet, il va rajouter une brique de gestion des liens à l'architecture MPLS.
Cette brique comprend un ensemble de procédures utilisées pour gérer les canaux et les erreurs
rencontrées sur ceux-ci. [12]

2.10.2 VPLS

VPLS (Virtual Private LAN Services) définit un service de VPN au niveau de la couche 2 (service
Ethernet) multipoint-à-multipoint qui peut être indifféremment délivré au niveau d’une
infrastructure métropolitaine ou sur des réseaux longue distance.
Ce service apporte une connectivité entre plusieurs sites comme si ces sites étaient reliés par un
même LAN Ethernet.

2.11 Sécurisation des réseaux MPLS

L’utilisation d’IP-MPLS pour le transport de services temps réel impose une excellente
disponibilité du réseau. De tels services imposent notamment de pouvoir garantir un

31
rétablissement de la connectivité en moins de 50 ms, en cas de panne de lien ou de nœud IP-
MPLS.
Les méthodes actuelles de protection SDH (Synchronous Digital Hierarchy) permettent de garantir
ces temps de sécurisation. En revanche, elles sont très coûteuses en ressources car elles nécessitent
de dédier des liens à la protection, et ne permettent de protéger le trafic que contre les pannes de
liens, et non contre les pannes de routeur. Il est donc préférable de réaliser la sécurisation des liens
et des routeurs directement au niveau de la couche IP-MPLS.
Les pannes des éléments du réseau peuvent être d’origines diverses. Ainsi les pannes de liens
peuvent être la cause d’erreurs sur des chantiers de travaux publiques (coups de pelleteuse sur une
fibre optique) ou plus simplement d’un lien débranché. En ce qui concerne les routeurs, cela peut
provenir d’une panne de courant. A cela, il faut ajouter les pannes logicielles dues à des erreurs
humaines. [14]
Tous les éléments d'un réseau sont susceptibles de tomber en panne. Pour garantir un haut niveau
de disponibilité du réseau, il faut prévoir ces pannes et déterminer des méthodes automatiques
pour les détecter et assurer la continuité du service le plus rapidement possible.
Parmi les mécanismes de protection, nous allons décrire :
 le modèle de réparation globale (Backup).
 le modèle de réparation locale ou restauration d'un segment d'un LSP (Fast Reroute),
 la protection à plusieurs niveaux (Multi-Layer).

2.11.1 La protection de Chemin

Figure 2.13 : Protection du LSP par chemin de Backup

32
Le LSP de Backup est le mode de protection par défaut de MPLS-TE. Il faut distinguer deux sous
modes pour ce type de protection :
 Le mode « Head-End Backup » où le Backup n'est ni calculé ni signalé. Un nombre
important de paquets vont être perdus.
 Le mode « Stand-by LSP » est une extension de RSVP-TE où le Backup est signalé et prêt
à l'emploi. L'inconvénient dans ce cas est la surréservation de la bande passante.
Un LSP de secours pré-alloué peut être utilisé pour protéger plusieurs LSP primaires, ce qui
permet d'économiser des ressources.
Il faut également bien voir que tous les LSP n'ont pas besoin d'être protégés par ce type de
technique qui nécessite la pré-allocation des ressources. Cela peut faire l'objet d'un contrat entre
l'opérateur et ses clients : protection totale du LSP, protection partagée avec d'autres LSP, ou bien
pas de protection du tout.

2.11.2 La protection par reroutage local

MPLS peut aussi assurer la protection des liens et des routeurs localement en utilisant des
techniques de reroutage rapide (Fast Reroute). Il devient ainsi possible d'approcher le délai de 50
ms qu'offre la reconfiguration de liens dans un réseau SDH classique.
C'est une méthode qui permet d'assurer la continuité du service en cas de panne d'un lien ou d'un
nœud avec une interruption très faible du service. Le mode Fast Reroute qui est une extension de
RSVP-T assure la protection de liens pour un LSP. Cela permet le reroutage local et rapide des
trafics transportés par le LSP à travers un chemin contournant la panne.
La décision de reroutage est une décision locale complètement gérée par le routeur source du lien
en panne. Ce dernier établit un LSP de contournement quand il reçoit une notification de panne
par l'IGP ou par RSVP.

2.11.3 La protection multi-niveaux

Traditionnellement, l’étude de la tolérance aux pannes se base sur l’hypothèse de la panne unique
qui avec l’avènement des réseaux optiques, n’est plus acceptable. En effet, la panne d’une fibre
optique peut impacter plusieurs liens au niveau de la topologie IP-MPLS.
Le modèle à pannes multiples est basé sur la notion de SRLG (Shared Risk Link Group) ou encore
SRNG (Shared Risk Node Group) que l’on peut regrouper sous un même identifiant.

33
 Figure 2.14 : Sécurisation SRLG du LSP primaire

La figure 2.14 montre le cas d’un réseau IP/MPLS sur WDM (Wavelength Division
Multiplexing). Le lien (0-1) est implanté au niveau WDM par le chemin (A – C – B). On peut voir
que le LSP primaire emprunte le chemin (0 – 1 – 4) qui est nœuds disjoints au niveau IP/MPLS
avec le chemin de backup (0 – 2 – 4).
Ils partagent par contre, une ressource commune au niveau WDM qui est le lien (A – C). Le
second chemin de Backup (0 – 3 – 4) est nœuds disjoints aux niveaux IP/MPLS et WDM car ils ne
partagent aucune ressource commune au niveau de la topologie WDM.

2.12 Conclusion

Le protocole MPLS est au cœur de la stratégie cible de la plupart des opérateurs d’aujourd’hui.
Grâce à ses mécanismes de commutation de labels avancés ainsi que par sa simplicité de mise en
place sur des réseaux déjà existants, le MPLS est devenu une technologie phare de demain alliant
souplesse, évolutivité et performance pour un coût réduit.
MPLS jouera un rôle important dans le routage, la commutation et le passage des paquets à travers
les réseaux de nouvelles générations pour permettre la rencontre entre les besoins de service et les
utilisateurs du réseau.
Dans le chapitre qui va suivre, on va s’approfondir dans l’étude de dimensionnement du Backbone
MPLS.

34
 CHAPITRE 3 : DIMENSIONNEMENT DU BACKBONE MPLS

3.1 Introduction

Pour assurer la performance des réseaux, on doit optimiser la gestion de capacité et la gestion du
trafic. En effet, la gestion de capacité consiste à faire la planification, à contrôler le routage et à
gérer les ressources comme la capacité des liens et la capacité des buffers. Tandis que la gestion
du trafic consiste à conditionner le trafic et à gérer les files d’attente.

Dans ce troisième chapitre on va, dans la première partie, déterminer la capacité des liens dans un
réseau MPLS, tout en sachant que ce réseau supporte un trafic temps réel comme la voix et un
trafic data. La deuxième partie du chapitre explique la notion de « Traffic Engineering » et les
améliorations qu’il permet d’apporter à l’utilisation du réseau.

3.2 Dimensionnement d’un réseau offrant le service voix

Pour concevoir un réseau, il existe certains éléments auxquels on doit faire attention. En effet,
l’étude d’un réseau se fait en suivant des procédures successives :
 la planification du trafic : permet de déterminer le nombre de clients auxquels le service est
destiné ainsi que les différents types de services offerts par le réseau ;
 le choix de la topologie du réseau : permet de définir l’emplacement des nœuds, la
classification des nœuds c’est-à-dire le choix du nombre de nœuds d’entrée et du nombre
de nœuds du cœur dans un réseau dorsal MPLS ;
 le calcul de la capacité des liens. [15]

3.2.1 Dimensionnement du réseau d’accès

Considérons le scénario formé par les hypothèses suivantes : 5 sites S1, S2, S3, S4 et S5
Chaque site est formé d’un certain nombre d’utilisateurs respectivement N1, N2, N3, N4, N5

35
 Figure 3.01 : Topologie pour un service de la voix

3.2.1.1 Modèle de trafic

On suppose que la loi du trafic voix obéit à un processus de Poisson. La probabilité d’observer
alors k arrivées pendant un intervalle de temps t est donné par :

𝜆𝑡 𝑡 −𝜆𝑡
𝑃𝑘 𝑡 = 𝑒 (3.01)
𝑘!

λ : étant le taux d’arrivée

Le processus de Poisson peut s’interpréter de deux façons suivantes :
 une arrivée poissonienne signifie que la probabilité pour qu’un client arrive pendant dt est
à peu près égale à λdt.
 les arrivées poissoniennes signifient que les inter-arrivées sont de types exponentiels. En
effet le processus de Poisson relie le processus d’arrivée poissonien aux variables
aléatoires mesurant le temps d’inter-arrivée.
Le dimensionnement des réseaux offrant le service de la voix utilise les lois d’Erlang en se basant
sur l’hypothèse que les services sont exponentiels et que les arrivées sont de type poissonien.

3.2.1.2 Lois d’Erlang

On adopte les lois d’Erlang dans plusieurs projets du fait qu’elles donnent généralement des
résultats raisonnables. Les formules sont utilisées dans les conditions suivantes :
 le nombre de clients est supérieur au nombre de ressources disponibles pour les servir ;
 les demandes des clients sont indépendantes les unes des autres. [16]

36
La loi la plus utilisée est celle d’Erlang B dans les réseaux téléphoniques classiques. Pour la voix
sur IP, les opérateurs conservent toujours cette formule dans leur procédure de dimensionnement
du réseau d’accès. La loi d’Erlang B permet de calculer la probabilité qu’une demande de
ressource sera rejetée à raison de ressources non disponibles. La probabilité de blocage sera alors
égale à :
𝐴𝑛
𝑃𝑛 = 𝑛! 𝑖 = 𝐸 𝐴, 𝑛 (3.02)
𝑛𝐴
0 𝑖!

Où :
 n : le nombre de ressources disponibles
 A : le trafic offert
 : la probabilité que les n ressources soient occupées
 : la première formule d’Erlang qui est fonction de A et n

3.2.1.3 Débit d’accès

Le débit d’accès peut se calculer dans chaque site en utilisant les étapes suivantes :
 calculer le débit par appel
 calculer le nombre de circuits

a) Calcul du débit par appel

Le débit par appel peut être calculé en tenant compte des éléments suivants :
 les codecs audio utilisés au niveau de la couche application ;
 les différentes encapsulations au niveau des différentes couches (transport, réseau) ;
 les protocoles au niveau de la couche liaison. [17]

Pour chaque site, on suppose qu’on a un choix uniforme entre les différents utilisateurs des
différents paramètres : codec, cycle de transmission, protocole de couche liaison.
La formule qui permet de calculer le débit par appel est la suivante :

𝐷 𝑏𝑖𝑡𝑎𝑝𝑙 = [ 𝐷 𝑏𝑖𝑡𝑐𝑜𝑑𝑒𝑐 ∗ 𝑐𝑦𝑐𝑙𝑒𝑡𝑟𝑎𝑛𝑠 + 𝑒𝑛𝑡 𝑡𝑒𝑅𝑇𝑃 𝑈𝐷𝑃 𝐼𝑃

(3.03)
+ 𝑒𝑛𝑡 𝑡𝑒𝑝𝑟𝑜𝑡𝑜𝑐𝑜𝑙𝑒𝑙𝑖𝑎𝑖𝑠𝑜𝑛 +𝑒𝑛𝑞𝑢𝑒𝑢𝑒𝑝𝑟𝑜𝑡𝑜𝑐𝑜𝑙𝑒𝑙𝑖𝑎𝑖𝑠𝑜𝑛 ] ∗ 8 𝑐𝑦𝑐𝑙𝑒𝑡𝑟𝑎𝑛𝑠

37
Avec :
 : débit par appel en Kbit/s ;
 : débit généré par le codec en Kbit/s ;
 : le cycle de transmission de paquet en ms ;
 : la taille de l’en-tête RTP/UDP/IP à ajouter en octets ;

 : la taille de l’en-tête du protocole de couche liaison en octets ;

 : la taille de l’enqueue du protocole de couche liaison.

b) Calcul du nombre de circuits

L’algorithme de la formule d’Erlang inverse permet de déterminer le nombre de circuits à mettre
en œuvre pour supporter un trafic donné avec une probabilité de blocage fixe.

Figure 3.02 : Algorithme d’Erlang inverse

Avec :
 A : trafic offert ;
 n : nombre de circuit ;
 E : formule d’Erlang ;
 p : probabilité de blocage fixé par l’opérateur.
On peut calculer la bande passante nécessaire à partir du nombre de circuits et le débit par appel.

𝑏𝑎𝑛𝑑𝑒 = 𝐷 𝑏𝑖𝑡𝑎𝑝𝑙 ∗ 𝑛𝑏 𝑐𝑖𝑟𝑐𝑢𝑖𝑡 (3.04)

La même méthodologie sera appliquée pour les autres sites.

38
3.2.2 Réseau dorsal IP/MPLS

Dans cette partie, on va détailler le calcul des capacités pour les différentes artères.

3.2.2.1 Choix de la topologie

La topologie à mettre en œuvre est présentée par la figure 3.03.

Figure 3.03 : Backbone MPLS

Le réseau dorsal MPLS est formé par 5 routeurs à la périphérie (LER) et quatre routeurs au cœur
du réseau (LSR). Pour des raisons de simplification, on suppose que les Edge Router n’effectuent
pas d’opération de commutation des paquets. En plus, les flux entrants au domaine MPLS par un
« Ingress LSR » ayant pour destination un « Egress LSR » qui lui est adjacent doivent passer
obligatoirement par un LSR appartenant au cœur du Backbone MPLS. Les numéros en noir
représentent les métriques des liens associés aux distances. Les représentent les numéros des
liens et ceci pour tout i de 1 à 13. [15]

39
3.2.2.2 Le débit à la sortie du routeur d’accès LER

Supposons que chaque site est lié à un Edge Router et que le débit d’accès sera le trafic à l’entrée
de chaque LER. MPLS est un protocole qui fonctionne entre la couche réseau et la couche liaison.
Le format de l’en-tête MPLS est décrit dans le chapitre 2.

3.2.2.3 Débit pour le cas de l’Ethernet

Le débit à la sortie du LER dans ce cas sera différent de celui à l’entrée puisque l’ajout d’un en-
tête MPLS à 4 octets va influer sur le débit. La procédure de calcul de débit sera semblable à celle
de calcul du débit par appel mais dans ce cas, on ajoute l’en-tête MPLS entre les couches 2 et 3.
On peut de cette manière estimer le trafic entre les différents routeurs de la périphérie deux à deux
pour construire une matrice de trafic. [18]
La distribution du trafic à l’entrée de chaque Edge Router se fait selon :
 le nombre d’utilisateurs liés à chaque site ;
 le plus court chemin entre deux Edge Routers.
La matrice de trafic aura alors la forme suivante entre les différents nœuds :

0 𝐴2 𝐴 𝐴4 𝐴5
𝐴2 0 𝐴2 𝐴24 𝐴25
𝑇𝑡𝑟𝑎𝑓𝑖𝑐= 𝐴 𝐴 2 0 𝐴 4 𝐴 5 (3.05)
𝐴4 𝐴42 𝐴4 0 𝐴45
𝐴5 𝐴52 𝐴5 𝐴54 0

3.2.2.4 Calcul des capacités

a) Capacité du plus court chemin entre deux LER

Supposons qu’on s’intéresse aux trafics et entre les nœuds 1 et 3. Ces trafics suivront le
plus court chemin entre ces deux nœuds. Les différentes métriques possibles sont 31, 36, 23, 42,
35 et 50. Donc le plus court chemin sera celui qui passe par les routeurs internes 1’- 4’- 3’ à
travers les liens L3, L13, L8 et L6. C’est ce chemin qui véhicule la totalité du trafic entre les
nœuds 1 et 3. Ce chemin doit être capable de supporter le maximum de charge entre ces deux
nœuds. Dans tous les cas, le trafic suit le plus court chemin pour des raisons de coût et de qualité
de service puisque le plus court chemin assure généralement un délai faible. Le chemin le plus

40
court doit supporter la somme des deux trafics étant donné que les artères sont considérées en full-
duplex.
Dans le processus de dimensionnement, on doit tenir compte d’un autre facteur à part la qualité de
service, à savoir la disponibilité du réseau. Pour cela, si le plus court chemin est incapable de
véhiculer le trafic entre deux sites donnés, les chemins alternatifs doivent partager ce trafic suivant
des coefficients basés sur des métriques de distances croissantes. En d’autres termes, plus le
chemin alternatif est court, plus la portion de trafic qu’il supporte sera importante. [21]

b) Capacité des liens individuels

Dans ce cas, on doit tenir compte des différents trafics acheminés entre les différents sites. On
suppose pour cela qu’il existe des trafics entre les différents sites. Au pire des cas, chaque lien doit
être dimensionné de telle façon qu’il supporte la totalité du trafic qui le traverse. [15]

𝑛− 𝑛

𝐶𝑘𝑣 = 𝛼𝑖𝑗𝑣 𝑇𝑖𝑗𝑣 (3.06)

𝑖= 𝑗=𝑖+

Avec :
 : la capacité du lien individuel pour le trafic voix
 : le trafic entre les sites i et j

 : un coefficient de pondération attribué au chemin supportant le trafic voix entre le site

i et le site j.

Etant donné qu’il existe plusieurs chemins entre deux nœuds i et j et étant donné que le plus court
chemin doit supporter la totalité du trafic, les autres chemins doivent partager le trafic entre eux
selon des coefficients de pondération.

3.2.2.5 Débit généré par la signalisation

La signalisation engendre un trafic qui peut charger le réseau et donc il est parfois nécessaire de
tenir compte de ce trafic lors du dimensionnement. Deux protocoles de signalisation peuvent être
mis en œuvre dans les domaines MPLS afin d’assurer la réservation des ressources et
l’établissement des LSP entre deux LER. Nous nous sommes intéressés à ce projet de trafic généré
par le protocole CR-LDP. Le choix du protocole CR-LDP est justifié par le fait que ce protocole a
été développé pour fonctionner sur MPLS alors le protocole RSVP a été adapté pour fonctionner

41
dans un domaine MPLS. Durant la phase de signalisation, on peut tenir compte uniquement du
débit engendré par:
 les messages d’affectation de label « Label Request » et « Label Mapping »
 les messages de libération de LSP « Label Release » et « Label Withdraw »

Le « Label Request » message est utilisé par un « Upstream LSR » pour demander à un
« downstream LSR » l’allocation de Label. D’une façon générale, c’est une requête
d’établissement de connexion.

Le message « Label Mapping » est utilisé par le « downstream LSR » pour annoncer la
construction d’un label pour une adresse de destination. Il est envoyé après la réservation de
ressources et l’établissement de connexion pour faire le « mapping » entre les « incoming label »
et les « outgoing label ». Il apporte le label assigné à la connexion à partir du « commutateur
downstream » au « commutateur upstream ».

Le message « Label Withdraw » est utilisé pour demander la libération d’un LSP. Ce message est
envoyé par un « downstream LSR » à un « upstream LSR » parce que c’est lui qui contribue à
l’affectation de label.

Le message «Label Release » est utilisé par un « upstream LSR » pour confirmer la libération
d’un LSP. Un « upstream LSR » peut envoyer un message « Label Release » sans recevoir un
message «Label Withdraw » à partir d’un « downstream LSR ».

Pour déterminer le trafic engendré par la signalisation, on a procédé comme suit :

 déterminer le nombre d’appels entre le nœud i et le nœud j quelque soit i et j

𝑁 𝑇𝑖 𝑗
𝑎𝑝𝑙𝑖 𝑗 = (3.07)
𝐷𝑎𝑝𝑙𝑖

Avec :
 : le trafic du site i au site j

 : le débit par appel au niveau du site i

42
  Calculer le débit de la signalisation : étant donné que les signalisations nécessaires à
l’établissement et à la libération ne s’effectuent pas en même temps, on peut dimensionner
les liens de telle manière qu’ils supportent la signalisation qui fournit plus de débit.
La signalisation entre deux sites tient compte du nombre d’appels et du débit de
signalisation.
𝑆𝑖 𝑗 = 𝑁𝑎𝑝𝑙𝑖 𝑗
∗ 𝐷𝑠𝑖𝑔𝑖 (3.08)

Avec :
 : le débit de signalisation par appel au niveau du nœud i

 : le nombre d’appels du nœud i au nœud j

𝑇𝑠𝑖𝑔
𝐷𝑠𝑖𝑔𝑖 =
𝑡𝑎𝑝𝑙 (3.09)

Avec :
 : taille de la signalisation par appel

 : durée d’un appel de i à j

Etant donné que les liaisons sont de type full-duplex, on doit tenir compte de la signalisation dans
les deux sens.

𝑆𝑖𝑗 = 𝑆𝑖 𝑗 + 𝑆𝑗 𝑖 (3.10)

Concernant la détermination de la capacité des liens pour la signalisation, on suit le même principe
que pour le trafic voix.

3.3 Dimensionnement pour un réseau offrant le service data

Jusqu’à aujourd’hui, le service data est le service dominant sur le réseau IP bien qu’on cherche à
intégrer d’autres services temps réel. Mais, ce service est moins prioritaire puisqu’il n’a pas de
contraintes de temps de transmission. Un consensus général existe sur le fait que le trafic data sur
IP n’est pas poissonien. Cependant les recherches ne sont pas d’accord sur l’approche qu’on peut
adopter pour modéliser le trafic sur Internet. [20]

43
Le modèle BMAP (Batch Markovian Arrival Process) a été exploité pour modéliser le trafic IP.
Ce modèle est conforme au trafic data où le besoin en débit des utilisateurs est aléatoire. En effet,
les flux arrivent parfois en lots, parfois l’activité des utilisateurs est nulle. Il est très difficile
d’estimer le trafic data généré par les utilisateurs. Pour le Web par exemple, la mesure du trafic se
base sur l’observation des traces des fichiers Log du coté client et du coté serveur (respectivement
Upload et Download). [15]

3.3.1 Etude d’un cas particulier

En se basant sur les contrats SLA (Service Level Agreement) entre les opérateurs et les abonnés
d’une part, et en partant d’un cas particulier de deux types de contrats d’autre part, qu’on a nommé
respectivement SLA1 et SLA2 :
 SLA1 : garantissant un débit montant de 64 Kbit/s et un débit descendant de 128 Kbit/s
 SLA2 : garantissant un débit montant de 128 Kbit/s et un débit descendant de 256 Kbit/s

Voici l’étape pour l’étude du trafic Data :

 Chaque site possède un nombre d’abonnés bien particulier. Pour chaque site, il y a un
certain pourcentage d’utilisateurs qui demandent un service de type SLA1 alors que les
autres demandent un service de type SLA2.
 Chaque trafic va transiter à travers un Backbone IP/MPLS pour atteindre le réseau Internet
qui est relié à un des Edge nodes du réseau dorsal.

3.3.2 Principe de distribution de charge

On a adopté la même topologie que dans le cas de la voix sauf qu’on a ajouté au niveau du site 4
une connexion à un réseau Internet. Par la suite, on va procéder comme suit :
 Calculer le débit du lien montant au niveau de chaque site selon les différents types de
contrats établis entre l’opérateur et les clients suivant un accès ADSL :

𝐷𝑢𝑝𝑖 = 𝑁 𝑖 ∗ 64 + 𝑁2𝑖 ∗ 128 (3.11)

Avec :
 : représente le nombre d’abonnés du site i ayant un contrat SLA1 ;
 2 : représente le nombre d’abonnés du site j ayant un contrat SLA2 ;

44
  Calculer le débit des liens descendants selon les conditions imposées par les contrats.

𝐷𝑑𝑜𝑤𝑛 𝑖 = 𝑁 𝑖 ∗ 128 + 𝑁2𝑖 ∗ 256 (3.12)

3.3.3 Capacité des liens

La détermination des capacités suivra le même principe que pour la voix.

3.3.3.1 Capacité du plus court chemin pour le trafic data

Le trafic dans les deux sens (montant et descendant) va suivre le plus court chemin. Ce dernier va
être dimensionné de telle façon qu’il supporte la totalité du trafic afin d’assurer certaines
exigences en terme de qualité de service tels que : un délai faible et un coût minimal. Il est
essentiel de prévoir d’autres chemins alternatifs qui vont partager respectivement les trafics upload
et download. Cette distribution de charge se fait selon des coefficients de pondération et elle est
utile surtout en cas de surcharge au niveau du plus court chemin ou lorsque ce chemin n’est pas
fonctionnel. [18]

3.3.3.2 Capacité des liens individuels pour le trafic data

Dans ce cas, on a suivi le même principe que pour le trafic voix. De façon générale, on suppose
que l’accès Internet est possible à partir d’un nœud i :
𝑛

𝐶𝑘𝑑 = 𝛼𝑖𝑗𝑑 𝑇𝑖𝑗𝑑

(3.13)
𝑗=
𝑖#𝑗

𝑇𝑖𝑗𝑑 = 𝑇𝑖 𝑗 + 𝑇𝑗 𝑖 (3.14)

Avec :
 : capacité du lien individuel k ;
 : coefficient de pondération attribué au chemin supportant le trafic data entre le nœud i
et le nœud j.

45
3.3.4 Capacité des liens supportant le trafic voix et data

Pour les liens qui vont supporter le trafic data et le trafic voix, la capacité du lien doit être capable
de supporter les deux trafics en même temps. La capacité totale doit être égale à la somme des
deux capacités, qui a été répartie suivant des coefficients entre le trafic temps réel (voix) et le
trafic élastique. Pour le trafic data, on n’a pas besoin de calculer le débit de la signalisation pour
connaître la capacité des liens. Le débit défini dans le contrat que l’opérateur doit garantir, tient
compte de la signalisation et de l’évolution du réseau. Pour cela, on peut ajouter un certain
pourcentage à la capacité du réseau. [19]

3.4 Les motivations du « traffic Engineering »

3.4.1 Principe du « traffic Engineering »

Figure 3.04 : Routage Classique

Dans la figure 3.04, il existe deux chemins pour aller de R2 à R6 :

 R2→R5→R6
 R2→R3→R6

En IP classique, le protocole de routage va se baser sur le critère du plus court chemin. Et puisque
tous les liens ont le même coût, les paquets venant de R1 ou R7 qui sont destinés à R6 vont tous
suivre le même chemin. [8]

46
Ceci peut conduire à quelques problèmes : supposons que tous les liens de la figure supportent une
bande passante de 150Mbps, et que R1 envoie en moyenne 90Mbps à R6. Le protocole de routage
va faire de telle 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. Au final, on aura deux trafics de 190Mbps qui veulent chacun utiliser le
chemin le plus court, 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 étant donné l’existence d’un chemin non exploité qui aurait permis de
satisfaire les deux trafics.
MPLS TE permet à l’« Ingress LER » de contrôler le chemin que son trafic va emprunter pour
atteindre une destination particulière. 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 3.05, LSR2 a la possibilité de construire deux LSP
(Tunnel1 et Tunnel2) relatifs aux chemins :
 LSR2→LSR5→LSR6
 LSR2→LSR3→LSR4→LSR6

Figure 3.05 : Le Trafic Engineering

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

La souplesse de l’utilisation des labels dans MPLS TE permet de profiter des avantages suivants :

47
 - 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 par re-routage : 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.).

3.4.2 Calcul et établissement des MPLS TE LSP

Aussitôt qu’un routeur se fait une idée de la topologie du réseau, il exécute le DSPFA (Dijkstra
Shortest Path First Algorithm) pour déterminer le plus court chemin entre lui-même et tous les
autres routeurs du réseau. 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. [10]
Le processus qui génère un chemin pour un MPLS TE LSP est différent du SPF (Short Path First)
classique. Deux différences majeures entre le SPF classique, utilisé par les protocoles de routage,
et le CSPF (Constrained Shortest Path First), utilisé par MPLS TE sont les suivantes:
- 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 d’OSPF
et IS-IS

A remarquer que l’administrateur n’est pas obligé de passer par CSPF pour calculer un MPLS 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 les 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.

48
La création d’un MPLS LSP non TE suit les deux étapes suivantes :
- calcul du MPLS LSP : mise en œuvre de l’algorithme SPF.
- établissement du MPLS LSP : mise en œuvre d’un protocole de distribution de label
« topology-based » (LDP, BGP, PIM (Protocol Independent Multicast)).

La création d’un MPLS LSP avec TE suit les deux étapes suivantes :
- calcul du MPLS LSP TE : mise en œuvre de l’algorithme CSPF ou intervention manuelle
de l’administrateur pour imposer une route explicite.
- établissement du MPLS LSP TE : mise en œuvre d’un protocole de distribution de label
« request-based » (RSVP TE, CR-LDP).

Après avoir calculé un chemin avec CSPF qui doit être signalé à travers le réseau afin de :
 établir une chaîne de labels qui représente le chemin ;
 réserver les ressources nécessaires à travers le chemin.

3.4.3 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 et que toute décision de routage est faite par
IGP. De ce fait, le seul travail de RSVP TE est de signaler et de maintenir la réservation de
ressources à travers le réseau.
En résumé, RSVP TE a trois fonctions de base :
 l’établissement et la maintenance des chemins
 la suppression des chemins
 la signalisation des erreurs
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 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. [11]

49
3.5 Conclusion

La détermination des capacités des différents liens au niveau du réseau est une des techniques de
son dimensionnement. Ainsi, les éléments à considérer sont le trafic généré par appels, le nombre
d’appels et la répartition des différents trafics entre les différents sites. Cette répartition est assurée
par la technique Trafic Engineering qui est un avantage considérable de la technologie MPLS.
Ainsi, le TE assure la modification et la distribution de charge comme le passage d’un service
voix à un service data dans le réseau.

50
 CHAPITRE 4 : SIMULATIONS ET RESULTATS

4.1 Les outils de simulation

On a besoin des outils de simulation lorsque la topologie du réseau est complexe ou les protocoles
sont difficiles à modéliser. Les informations relatives aux performances des réseaux sont obtenues
également par les outils de simulation. Ils sont alors utilisés pour évaluer le comportement d’un
réseau ainsi que ses performances en débit, délai, gigue quand tout approche théorique s’avère
impossible. Il existe plusieurs types de simulateurs permettant de modéliser les réseaux de
télécommunication, à savoir, OMNet++, NS2, OPNET Modeler et GNS3.

4.1.1 OMNET ++

OMNET++ est un logiciel Open Source de simulation à évènement discret programmé en C++. Il
dispose d’une interface graphique de programmation relativement claire et intuitive. Ce logiciel
offre une interface de programmation appelée langage GNED relativement proche de C.
OMNET++ est spécifique à la modélisation de réseaux informatiques. Ce logiciel présente peu de
documentation sur la technologie MPLS.

4.1.2 NS-2

NS-2 ou Network Simulator-2 est un simulateur de réseaux informatiques à évènement discret

orienté objet. Ce logiciel utilise le langage OTcl du système UNIX. NS-2 est plutôt dédié aux
technologies IP, aux protocoles identiques à TCP, aux différents protocoles de routage unicast et
multicast, aux protocoles MAC 802.3, 802.11. Désormais, la technologie MPLS dans NS-2 n’est
pas utilisée comme librairie standard.

4.2 Simulation avec OPNET Modeler

4.2.1 Description d’OPNET

OPNET est une famille des logiciels de modélisation et de simulation de réseaux s’adressant à
différent public tel que les entreprises, les opérateurs et la recherche. OPNET Modeler est la
version académique de cette famille. Il offre la possibilité de modéliser et d’étudier des réseaux de
communication, des équipements, des protocoles et des applications avec facilité et évolutivité.
OPNET est utilisé par les entreprises technologiques les plus performantes pour accélérer leurs
procédés de recherche et de développement. [22]

51
L’approche orientée objet associée à des éditeurs graphiques intégrés d’OPNET simplifie la
composition des réseaux et des équipements. Ceci permet de réaliser facilement une
correspondance entre un système d’information et un modèle correspondant.

4.2.2 Les outils d’OPNET

4.2.2.1 Les systèmes

OPNET Modeler fournit une librairie de modèle de matériel disponible dans le commerce. Ces
matériels peuvent être des routeurs, des commutateurs, des stations de travail et des générateurs de
trames.

Figure 4.01 : Exemple de matériels réseaux proposés par la palette d’objets MPLS

4.2.2.2 Les protocoles

OPNET Modeler fournit des modèles de protocole de routage de différentes couches du modèle
OSI, telles que TCP, IP, Ethernet, ATM, 802.11, etc…

4.2.3 Conception du réseau

OPNET Modeler utilise une série d’éditeur qui parallélise la structure du réseau réel, des
équipements et des protocoles.
La modélisation se construit de façon hiérarchique, il existe 4 niveaux à savoir, Projet, Réseau,
Nœud et Processus. [23]

52
4.2.3.1 Niveau Projet

C’est le niveau de conception le plus élevé. On peut regrouper plusieurs modèles de réseaux dans
un Projet. Cela peut être intéressant si on souhaite comparer les avantages et inconvénients de
deux solutions d’ingénierie distinctes.

4.2.3.2 Niveau Réseau

C’est à ce niveau qu’est représenté le réseau dans son ensemble. Un réseau est vu comme un
ensemble de nœuds éventuellement reliés par des liens ou bus.

Figure 4.02 : Exemple d’un réseau de routeur utilisant le protocole MPLS

4.2.3.3 Niveau Nœud

Ce niveau montre l’organisation des différentes machines à états et la façon dont ils
communiquent via des bus. Le niveau nœud permet de mettre en œuvre divers objets de type «
générateur de paquets », « Queue », « émetteur point à point », « bus », etc…

53
 Figure 4.03 : Modèle d’un nœud LER

4.2.3.4 Niveau Processus

Un processus est représenté comme une machine à états. Chaque état peut être ouvert (couleur
verte) ou fermé (couleur rouge). L’entrée dans un état ouvert est immédiatement et
automatiquement suivie de la sortie de cet état. Par contre, on ne sort d’un état fermé que lorsqu’il
advient un événement. Un événement provoque le passage d’un état à un autre.

54
 Figure 4.04 : Modèle de processus pour le protocole OSPF

4.2.3.5 Programmer le comportement des processus

Le processus de simulation est appelé « Simulation Kernel ». Il fait appel aux « Kernel
Procedure ». Les processus utilisateurs définis dans le modèle de processus font appel aux
« Kernel Procedure » par l’intermédiaire du langage C ou C++. Ces procédures permettent de
définir non seulement le comportement des processus mais aussi selon quelles lois statistiques les
paquets sont émis dans le réseau et enfin de mettre à jour les statistiques. OPNET Modeler ne
comporte pas de compilateur mais utilise celui de Microsoft Visual Studio.

4.2.4 Le choix d’OPNET Modeler

Notre choix d'OPNET Modeler se base sur le fait qu'il est l'un des meilleurs logiciels de
simulation de réseaux présent sur le marché. Il existe une version académique intégrant les
paramètres et les protocoles utilisés dans notre simulation. Son interface claire et conviviale
présente un bon avantage.

55
4.3 Mise en œuvre

Dans cette modélisation, nous avons utilisé OPNET Modeler 14.5 pour étudier la performance de
la VoIP sur un Backbone MPLS avec « traffic Engineering ». Pour ce faire, deux scénarii de cœur
de réseaux sont configurés pour intégrer le service VoIP et pour supporter les trafics IP « Best
Effort ». En effet, le premier scénario modélise un Backbone utilisant le protocole BGP et le
second un Backbone utilisant la technologie MPLS avec « Traffic Engineering ».

4.3.1 Modélisation du réseau sans la technologie MPLS

4.3.1.1 Choix de la topologie

La première étape dans la modélisation d’un réseau est sa schématisation. Pour ce faire, nous
avons implémenté une architecture du Backbone basé sur 7 routeurs cœurs du réseau
interconnectés avec des liens SONET OC3 de capacité 155 Mo, et deux systèmes autonomes
composés de 3 routeurs chacun rattachés au Backbone. Cette architecture est déployée avec le
protocole I-BGP comme protocole de routage au niveau de chaque système autonome et E-BGP
comme protocole de routage entre les systèmes autonomes. Le choix du protocole BGP vient du
fait qu’il est beaucoup plus robuste par rapport aux autres protocoles comme OSPF, RIPv2.

La figure 4.05 présente la topologie physique du réseau de cette simulation. Le système autonome
jaune est formé par les 3 routeurs suivants :
 A_3_Rtr1 ;
 A_3_Rtr2 ;
 A_3_CE.
Pour que ces 3 routeurs forment un système autonome, il faut que la valeur du paramètre AS
(Autonomous System) soit égale à 2.
Le système autonome vert, qui a pour valeur 4 pour le paramètre AS, est constitué par les 3
routeurs suivants :
 A_1_Rtr1 ;
 A_1_Rtr2 ;
 A_1_CE.

56
 Figure 4.05 : Topologie de la simulation

4.3.1.2 Configuration du réseau

La figure 4.06 montre la topologie de la simulation avec les numéros des interfaces actives de
chaque routeur.

Figure 4.06 : Topologie de la simulation avec les numéros des interfaces actives

4.3.1.3 Plan d’adressage

- Au niveau du Backbone
Le tableau 4.01 donne le plan d’adressage des 7 routeurs constituant le Backbone.

57
 Routeurs Interfaces Adresses Masque de Protocoles de Système
sous réseau routage autonome
IF0 192.0.17.1
IF1 192.0.11.1 /30 I-BGP(OSPF) 1
Site1_PE IF2 192.0.10.2 E-BGP(IF0)
LB0 192.0.24.1 /32
IF1 192.0.14.1
Site2_PE IF2 192.0.13.1 /30 I-BGP(OSPF) 1
LB0 192.0.25.1 /32
IF0 192.0.18.1
IF1 192.0.16.2 I-BGP(OSPF)
Site3_PE IF2 192.0.15.1 /30 E-BGP(IF0) 1
IF3 192.0.9.2
LB0 192.0.26.1 /32
IF0 192.0.15.2
IF1 192.0.13.2 /30
Rtr1 IF2 192.0.12.1 I-BGP(OSPF) 1
LB0 192.0.27.1 /32
IF0 192.0.9.1
Rtr2 IF1 192.0.8.1 /30 I-BGP(OSPF) 1
LB0 192.0.23.1 /32
IF0 192.0.14.2
IF1 192.0.12.2
IF2 192.0.11.2 /30 I-BGP(OSPF) 1
Rtr3 IF3 192.0.8.2
LB0 192.0.31.1 /32
IF0 192.0.16.1 /30
Rtr4 IF1 192.0.10.1 I-BGP(OSPF) 1
LB0 192.0.22.1 /32

Tableau 4.01: Plan d’adressage du Backbone

Le protocole E-BGP est sollicité au niveau des 2 routeurs Sit1_PE et Site3_PE. En effet, on
préfère utiliser ce type de protocole pour assurer la commutation des paquets entre le système
autonome jaune et le Backbone à travers le routeur Site1_PE, de même que le système autonome
vert à travers le routeur Site3_PE. Ainsi, les interfaces IF0 sont configurées pour ces deux types de
routeurs afin de supporter ce type de protocole.

- Au niveau du système autonome jaune

Le tableau 4.02 suivant donne le plan d’adressage des 3 routeurs constituant l’AS 2

58
 Routeurs Interfaces Adresses Masque de Protocole de Système
sous réseau routage autonome
IF0 192.0.21.1
A_3_CE IF1 192.0.19.1 /30 I-BGP(RIPv2)
IF2 192.0.18.2 EBGP(IF2) 2
LB0 192.0.34.1 /30
IF0 192.0.21.2 /30
A_3_Rtr1 IF1 192.0.20.2 I-BGP(RIPv2) 2
LB0 192.0.36.1 /32
IF0 192.0.20.1
A_3_Rtr2 IF1 192.0.19.2 /30 I-BGP(RIPv2) 2
LB0 192.0.35.1 /32

Tableau 4.02: Plan d’adressage du AS 2

- Au niveau du système autonome vert

Le tableau 4.03 suivant donne le plan d’adressage des 3 routeurs constituant l’AS 4

Routeurs Interfaces Adresses Masque de Protocole de Système

sous réseau routage autonome
IF0 192.0.17.2
A_1_CE IF1 192.0.4.1 /30 IBGP(RIPv2)
IF2 192.0.2.1 EBGP(IF2) 4
LB0 192.0.31.1 /32
IF0 192.0.4.2 /30
A_1_Rtr1 IF1 192.0.3.2 IBGP(RIPv2) 4
LB0 192.0.33.1 /32
IF0 192.0.3.1
A_1_Rtr2 IF1 192.0.2.2 /30 IBGP(RIPv2) 4
LB0 192.0.32.1 /32

Tableau 4.03: Plan d’adressage du AS 4

4.3.1.4 Configuration du protocole de routage

Le Protocole BGP
La configuration du protocole BGP se repose sur la définition des 2 paramètres à savoir, la famille
d’adresse IPv4 et les routeurs voisins ou « neighboors ».
- La famille d’adresse IPv4
La figure 4.07 nous montre la configuration de la famille d’adresse IPv4 pour le routeur Site1_PE.

59
 Figure 4.07 : Configuration de la famille d’adresse IPv4 du routeur Site1_PE

- Les routeurs voisins ou « neighbors »

La figure 4.08 nous montre les « neighbors » pour le routeur Site1_PE

Figure 4.08 : Configuration des « Neighbors » du routeur Site1_PE

La table « neighbors » d’un routeur contient les adresses LB0, les systèmes autonomes et les
propriétés respectives de ses routeurs voisins. Elle permet au routeur de savoir s’il s’agit d’un I-

60
BGP ou d’un E-BGP. Si le paramètre « Remote AS » possède la même valeur que celle du
système autonome du routeur alors il s’agit d’un I-BGP (figure 4.08, cas de la valeur encerclée en
bleue). Par contre, si la valeur est différente alors il s’agit d’un E-BGP (figure 4.08, cas de la
valeur encerclée en vert).

4.3.2 Modélisation du réseau avec la technologie MPLS

4.3.2.1 Choix de la topologie

Pour la modélisation du réseau avec la technologie MPLS, la topologie de simulation restera la

même que celle de la technologie sans MPLS précédente. La différence se trouve au niveau de la
configuration du protocole de routage dans le Backbone. En effet, au lieu d’utiliser le protocole
BGP, on a choisi le protocole MPLS. L’avantage de ce dernier ne se limite pas sur le fait qu’il est
rapide en termes de commutation de paquets mais sur le fait qu’on peut bénéficier de l’ingénierie
de trafic.
La figure 4.09 nous montre la topologie de simulation du réseau avec la technologie MPLS et le
« traffic Engineering »

Figure 4.09 : Topologie de simulation avec MPLS Trafic Engineering

61
4.3.2.2 Configuration du Backbone MPLS

Contrairement au Backbone BGP, le Backbone MPLS est structuré de telle sorte que les routeurs
n’effectuent pas les mêmes fonctions. En effet, il existe deux types de routeurs à savoir :
- PE (Provider Edge): Site3_PE, Site1_PE, Site2_PE : ces routeurs jouent le rôle de LER.
- LSR : Rtr1, Rtr2, Rtr3, Rtr4.

La configuration se repose sur les paramétrages des routeurs PE et LSR.

a) Configuration du routeur PE
Pour paramétrer un routeur PE, il faut définir la famille d’adresse IPv4 et les « neighbor » comme
la configuration qu’on a vue avec les routeurs qui constituent le Backbone BGP. La différence se
trouve dans la définition des « neighbors ». Dans le routeur PE, « les neighbors » ayant le système
autonome local sont constitués seulement des routeurs LER qui forment le Backbone MPLS.
La figure 4.10 présente la table des « neighbors » pour le routeur Site1_PE.

Figure 4.10 : Configuration des Neighbors du routeur Site1_PE dans le cas du Backbone MPLS

b) Configuration du routeur LSR

La configuration du routeur LSR ne tient compte ni de la famille d’adresse IPv4 ni des
« neighbors », il se contente uniquement de commuter les paquets vers sa destination.

62
 Figure 4.11 : Configuration du routeur LSR Rtr1

4.3.3 Les types de trafic circulant dans le Backbone

On va considérer deux types, le trafic VoIP et le trafic IP « Best Effort ». Notre étude se focalise
surtout sur l’analyse des paramètres de la VoIP en étudiant ses comportements que ce soient dans
le Backbone utilisant le protocole BGP ou dans le Backbone MPLS avec « Traffic Engineering ».

4.3.3.1 Le trafic VoIP

Le choix du trafic VoIP est du fait qu’il est très sensible aux délais par rapport aux flux vidéo.
Notre trafic VoIP est configuré avec un type de service « interactive voice » et sensible aux
paramètres délai, débit et reliabilité.

63
 Figure 4.12 : Configuration du TOS du trafic VoIP

Le trafic VoIP est configuré entre le système autonome 4 : Site 1 : A_1_Rtr1 et le système
autonome 2 : Site 3 : A_3_Rtr1 avec les paramètres d’entrée suivants :
- Débit d’appel : 500 appels par heure
- Durée moyenne d’appel : 300s (5min)
- Durée des flux de la VoIP : 90000s (25 heures)
La figure 4.13 montre le débit moyen qui est à 4Mbps pour le trafic VoIP.

Figure 4.13 : Débit moyen en bit/seconde du trafic VoIP pour un débit de 500 appels par heure

64
4.3.3.2 Le trafic IP « Best Effort »

Un Backbone peut intégrer d’autres types de services que la VoIP. Ainsi, pour avoir une
modélisation plus proche de la réalité, on a choisi le trafic IP « Best Effort » entre le système
autonome 4 : Site 1 : A_1_Rtr1 et le système autonome 2 : Site 3 : A_3_Rtr1 avec les paramètres
d’entrées suivants :
- Type de service : « Best Effort »
- Débit moyen : 45Mbps

Figure 4.14 : Débit moyen en bit/seconde du trafic IP « Best Effort »

4.3.4 Mise en œuvre du TE dans le Backbone MPLS

Le Backbone MPLS est configuré de telle manière que les trafics VoIP et IP « Best Effort »
suivent des LSP différents. Pour ce faire, on a besoin de suivre quelques étapes :
- la définition des deux paramètres tels que les FEC et les « traffic Trunking » ;
- la définition des deux LSP, un pour le trafic VoIP et un autre pour le trafic IP « Best
Effort » ;
- la configuration des routeurs LER pour supporter le « traffic Engineering ».

4.3.4.1 Définition des FEC

Une FEC se compose d’une ou plusieurs entrées permettant de spécifier un trafic. Pour chaque
entrée, les adresses IP source et destination, les ports de transport source et destination, le type de

65
protocole transporté ainsi que la valeur du champ ToS peuvent être utilisés pour cette
spécification. Un LER, qui reçoit un paquet correspondant à la définition d’une des entrées d’une
FEC, acheminera ce paquet sur le LSP correspondant à cette FEC.
La figure 4.15 présente les différentes options permettant de caractériser les trafics recherchés par
les FEC.

Figure 4.15 : Définition des FEC

4.3.4.2 Définition des « traffic trunking »

Un « traffic trunking » ne fait pas partie des fondements de la technologie MPLS. Dans un réseau
MPLS sans ingénierie de trafic, les paquets caractérisés par une FEC suivent le LSP
correspondant. Le « traffic trunking » est un concept relié à l’ingénierie de trafic. Pour déplacer le
trafic là où il y a la bande passante, la FEC n’associe pas le trafic à un autre LSP, c’est le « traffic
trunking » qui est associé à un autre LSP. Lorsque l’ingénierie de trafic est utilisée, la FEC associe
un trafic à un « traffic trunking » qui est lui-même associé à un ou plusieurs LSP.

66
 Figure 4.16 : Table des profils de Trunk

Pour notre simulation, nous avons configuré un profil de « Trunk » pour le trafic voix et un autre
pour le trafic IP « Best Effort ». Le profil de « Trunk » associé à la voix est caractérisé par un
débit maximum de 10 Mbps et moyen de 7 Mbps. Le trafic excédentaire ne sera pas supprimé et la
classe de service du « Trunk » est « Expedited Forwarding » afin d’assurer la bande passante
désirée et de minimiser le délai et la gigue des paquets de la voix.

Pour le trafic IP « Best Effort », un « Trunk » différent sera utilisé afin de marquer ce trafic avec
une classe de service différente. Ce « Trunk » aura un débit maximum de 45Mbps et moyen de
40Mbps. Le trafic excédentaire ne sera pas supprimé et la classe de service sera « Assured
Forwarding » 41.

4.3.4.3 Configuration du routeur LER pour supporter le TE

Pour finaliser la configuration, il faut paramétrer le routeur LER en associant les FEC au LSP.
Chaque type de trafic doit être associé avec le chemin de commutation d’étiquettes spécifiques
correspondantes, et qui transporte de trafic jusqu’au routeur PE de destination. L’association de
trafic vers le LSP est effectuée sur le routeur de périphérique LER.

67
 Figure 4.17 : Association des FEC aux LSP

Le trafic voix sera acheminé à travers le LSP rouge (Site1_PERtr4Site3_PE) tandis que le
trafic IP « Best Effort » suivra le LSP marron (Site1_PERtr3Rtr1Site3_PE).

4.4 Analyse des Résultats

4.4.1 Observations des trafics envoyés et reçus

Pour chaque scenario, la durée de simulation est de 25 heures. Les figures 4.18 et 4.19 montrent
respectivement les débits moyens des trafics IP « Best Effort » et VoIP envoyés et reçus entre les
routeurs A1_Rtr1 et A3_Rtr1. Les trafics IP « Best Effort tendent vers une stabilité de charge
moyenne 45Mbps. Tandis que pour le trafic VoIP, on constate que les trafics tendent vers une
stabilité de charge 4Mbps après quelques heures d’observation.
On peut dire le réseau fonction en respectant la condition telle que les paquets envoyés par le
routeur A1_Rtr1 sont reçus par le routeur A3_Rtr1.
L’ensemble de trafic circulant dans le Backbone est la somme des trafics VoIP et IP « Best
Effort » qui est égale à 49 Mbps.

68
 Figure 4.18 : Débits des trafics IP « Best Effort » envoyés et reçus

Figure 4.19 : Débits des trafics VoIP envoyés et reçus pour 500 appels/heure

4.4.2 Comparaison de la répartition des charges

Les figures 4.20 et 4.21 présentent respectivement la répartition des charges dans le Backbone
pour les deux scénarii.

69
 Figure 4.20 : Répartition de la charge dans le Backbone MPLS

Figure 4.21 : Répartition de la charge dans le Backbone BGP

Pour le Backbone BGP, toutes les charges du réseau sont supportées par le lien Site1_PE Rtr4
Site3_PE tandis que pour le Backbone MPLS les charges sont réparties telles que le lien
Site1_PE Rtr4 Site3_PE supporte le trafic VoIP et le lien Site1_PERtr3Rtr1Site3_PE
supporte le trafic IP « Best Effort ».

70
4.4.3 Impacts de la répartition des charges

4.4.3.1 « IP Background delay »

« IP Background Delay » représente le délai des flux (IP « Best effort » et VoIP) entre la source et
la destination. La figure 4.22 montre que ce délai pour le Backbone qui utilise le protocole BGP
est supérieur par rapport à celui du Backbone MPLS.

Figure 4.22 : Le paramètre « IP Background Delay » pour les deux scenarii

4.4.3.2 « End to end delay »

« End to end delay » est le temps que le paquet met pour atteindre sa destination en seconde. Il est
mesuré par la différence entre le temps de création du paquet et le temps de son arrivée à sa
destination. Cette statistique est collectée séparément pour chaque paire de source et destination.
Seulement les paquets unicast générés explicitement sont considérés. La figure 4.23 présente
l’« end to end delay » entre le routeur Site1_PE et Site3_PE pour les deux scénarii. On constate
que le Backbone MPLS donne une valeur faible par rapport au Backbone simple pour ce type de
paramètre.

71
 Figure 4.23 : Le paramètre « End to end delay » pour les deux scénarii

4.4.3.3 « End to end delay variation »

Figure 4.24 : Le paramètre « End to end delay Variation » pour les deux scénarii

« End to end delay variation » est la variation du temps que le paquet met pour atteindre sa
destination. Il est calculé selon la formule suivante :

2
𝐷𝑣𝑎𝑟 = 𝐷𝑖𝑛𝑠𝑡 − 𝐷𝑚𝑜𝑦𝑒𝑛 (4.01)

72
Avec
 : Délai à l’instant t
 : Délai moyen
La figure 4.24 présente l’« end to end delay variation » entre le routeur Site1_PE et Site3_PE pour
les deux scénarii. On remarque que le temps de variation est beaucoup plus élevé dans le
Backbone simple comparé à celui du Backbone MPLS.

4.4.3.4 « Point to point Queuing delay »

Figure 4.25 : Le paramètre « Point to point Queuing Delay » pour les deux scénarii

Le « point to point Queuing delay » est le temps que le paquet est dans la file d’attente c’est-à-dire
la différence entre le temps d’entrée et le temps de sortie du dernier bit du paquet dans la file
d’attente pour être transmis. La figure 4.25 montre que les paquets passent plus de temps dans le
Backbone simple comparé au Backbone MPLS qui représente un délai faible d’attente des paquets
dans la file d’attente entre les routeurs Site1_PE et Site3_PE.

4.5 Simulation avec GNS3

Pour montrer l’implémentation de la VoIP sur un Backbone MPLS, on a choisi le simulateur

GNS3. En effet, ce dernier offre plusieurs types de routeurs qui supportent à la fois la technologie
MPLS et la « telephony-service ». Le routeur CISCO 3600 est employé dans notre simulation.

73
Ainsi, pour générer du trafic VoIP, on a utilisé l’ « IP Phone » version 7 de CISCO appelé aussi
« CISCO IP Communicator V7 ».

4.5.1 La topologie du réseau

La topologie du Backbone restera la même que celle qu’on a vue dans la première partie de ce
chapitre. Elle est représentée par la figure 4.26.

Figure 4.26 : Topologie avec GNS3

4.5.2 Implémentation du « Traffic Engineering » avec CISCO 3600

L’application VPN de MPLS offre une meilleure facilité d’implémentation du « Traffic

Engineering ». On a créé un tunnel spécifique pour acheminer la voix, défini par le chemin
Site1Pe-Rtr4-Site3Pe. L’idée est de définir les chemins utilisés par les flux VPN-MPLS. Pour ce
faire, On va associer à chaque VRF qu’on veut contraindre les flux sur chaque PE une interface
« loopback ».

Router1#(conf) ip vrf definition Voice

Routeur1#(conf-vrf) rd 65:1
Routeur1#(conf-vrf) route-target export 65:1
Routeur1#(conf-vrf) route-target import 65:1
Routeur1#(conf-vrf) address-family ipv4
Routeur1#(conf-vrf) bgp next-hop Loopback10

74
L’adresse de cette « loopback » sera le « next-hop » BGP des routes clients transportées dans le
VPN-MPLS correspondant. Il suffit de router statiquement l’adresse « loopback » dans le tunnel
avec une simple route statique (voir annexe 5).

4.5.3 Réalisation d’un appel entre deux IP Phones

Pour que les IP Phones soient fonctionnels, il faut configurer les routeurs A3Rtr1 et A1Rtr1 afin
qu’ils supportent la « telephony service ». Considérons que le routeur A1Rtr1 attribue le numéro
201 au Client1 et A3Rtr1 donne le numéro 100 au Client3. Les deux IP Phones sont installés
respectivement dans deux machines. Chaque IP Phone utilise l’interface réseau de la machine sur
laquelle il est installé. Une fois que la configuration du routeur et l’installation des IP Phones sont
finies, on peut effectuer un appel entre les deux clients.

Figure 4.27 : Exemple d’un appel entre deux IP Phones

4.5.4 Analyse des trafics capturés avec Wireshark

On peut dire que les trafics VoIP sont sécurisés grâce à l’utilisation du VPN. En outre, le
protocole MPLS dans notre cas est spécifié pour les trafics Unicast.

75
 Figure 4.28 : Capture du lien Rtr4-Site3PE avec Wireshark

4.6 Conclusion

En somme, face à la sensibilité de la VoIP aux paramètres délai, gigue et perte de paquet, il est
important de trouver la meilleure technique pour minimiser ces trois paramètres. Ce chapitre a
pour but de comparer la performance du Backbone MPLS avec trafic Engineering et du Backbone
BGP sur le trafic VoIP. Nous avons observé que le Backbone MPLS est beaucoup plus performant
en termes de délai, de gigue et de perte de paquet. De ce fait, il est conseillé d’utiliser la technique
MPLS pour notre Backbone afin d’assurer une qualité de service aux utilisateurs surtout pour
l’intégration de la VoIP.

76
 CONCLUSION GENERALE

Actuellement, les opérateurs de télécommunication misent beaucoup d’investissements sur les

réseaux de télécommunication modernes, vu leur utilité, leur facilité d’utilisation et d’intégration
de nouvelle gammes de service.

Dans ce mémoire, on s’est intéressé à la performance du transfert de la voix sur un Backbone

utilisant la technologie MPLS. Ainsi, des simulations sous OPNET Modeler et sous GNS3 sont
mises en œuvre afin d’effectuer une étude comparative de la VoIP sur un Backbone utilisant le
protocole BGP et un autre utilisant le protocole MPLS avec ingénierie de trafic.

Il nous a aussi permis de comprendre le principe du protocole MPLS. Par rapport au protocole IP,
MPLS offre les avantages du mode connecté tout en conservant la souplesse du mode non
connecté. Cette technologie diminue le temps de transit dans les réseaux d’une part, et
l’ingénierie de trafic offre une haute disponibilité dans les réseaux d’autre part. Par aileurs, cette
technologie permet au Backbone non seulement d’assurer les paramètres que la VoIP exige, mais
aussi la garantie de transfert et la disponibilité de la bande passante.
De tout ce qui précède, la gestion des flux de trafic, l’optimisation de la détermination de
l’acheminement des paquets constituent des améliorations conséquentes par rapport aux
technologies utilisées pour les trafics VoIP

Dès lors, d’autres types de routeurs, comme les giga-routeurs, présentent une performance en
terme de rapidité de commutation et peuvent concurrencer par la suite MPLS.

77
 ANNEXE 1 MODELE OSI

Le modèle OSI a été développé en 1978 par l’ISO (International Organisation of Standard) afin
que soit défini un standard utilisé dans le développement de système ouvert. Les réseaux
s’appuyant sur les spécifications de l’OSI « parlent le même langage », c’est-à-dire qu’ils utilisent
des méthodes de communication semblables pour échanger des données.
Voici les différentes couches en partant du niveau le plus bas :
 Physique
 Liaison des données
 Réseau
 Transport
 Session
 Présentation
 Application
Cinq principes de base s’appliquent aux différentes couches :
- Une couche ne peut être créée que quand un niveau différent d’abstraction est nécessaire.
- Chaque couche doit fournir une fonction bien définie.
- La fonction de chaque couche doit être choisie de façon à définir internationalement les
protocoles standards.
- Les caractéristiques d’une couche doivent être choisies pour qu’elles réduisent les
informations transmises entre les couches.
- Des fonctions différentes doivent être définies dans des couches différentes, mais il faut
éviter d’augmenter le nombre de couches pour que l’architecture ne devienne pas trop
compliquée.

L’application de ces cinq principes crée un modèle idéal, où chaque couche effectue une seule
fonction et dépend des services de la couche immédiatement inférieure. De même, chaque couche
fournit ses services à la couche immédiatement supérieure. La couche réseau, par exemple, utilise
les services de la couche immédiatement inférieure, liaison des données, et fournit ses services à la
couche transport, immédiatement supérieure.

78
 ANNEXE 2 : PROTOCOLES DE ROUTAGE

A2.1 RIP
Le protocole RIP est un exemple de classe de protocoles appelée « protocoles à vecteurs de
distance ». Dans les protocoles à vecteurs de distance, le routeur tient à jour dans sa table de
routage une liste de toutes les routes connues et diffuse périodiquement le contenu de cette table.
Chaque entrée de la table est composée de la destination, de la distance et du routeur de prochain
pas.
A2.2 OSPF
Le protocole OSPF a été conçu au sein de l’IETF (Internet Engineering Task Force) à la fin des
années 80. Il utilise plusieurs critères pour sélectionner le meilleur chemin vers une destination.
Ces critères incluent des métriques de coût qui tiennent compte notamment de la vitesse
d’acheminement, du trafic, de la fiabilité et de la sécurité. Il n’utilise pas de vecteur de distance
mais base ses décisions de routage sur le concept d’état des liaisons.
A2.3 IS-IS
Le protocole IS-IS (Intermediate System to Intermediate Système) a été principalement dévéloppé
par l’ISO ; il décrit un routage hiérarchique fondé sur la décomposition des réseaux de
communication en domaine. Dans un domaine, les différents nœuds indiquent leur état aux
routeurs IS-IS afférents. Les communications inter-domaines sont effectuées par un routage vers
un point d’accès au domaine, déterminé par les routeurs chargés des communications externes au
domaine.
A2.4 IGRP
Le protocole IGRP a été défini par la société Cisco pour ses routeurs. Elle intègre le routage multi-
chemin, la gestion des routes par défaut, la diffusion de l’information toutes les 90 secondes au
lieu de toutes les 30 secondes, la détection des bouclages, etc.
A2.5 EIGRP
Le protocole EIGRP est une amélioration du protocole IGRP, il offre une protection plus efficace
contre les boucles.
A3.6 BGP
C’est un protocole qui définit les échanges à l’intérieur du domaine (I-BGP) et entre systèmes de
bordure (E-BGP).

79
 ANNEXE 3 DATAGRAMME IP

La figure A3.01 présente la structure du datagramme IP.

Figure A3.01 : Structure du datagramme IP

 VER : version du protocole IP codée sur 4 bits : 0100 pour IPv4 et 0110 pour IPv6.
 HLEN ou IHL (Internet Header Length) : codée sur 4 bits. Cette valeur est à multiplier par 4
pour connaître le nombre d’octets constituant l’en-tête. L’en-tête correspond au début du
datagramme jusqu’aux données. Il permet notamment de savoir s’il y a des options et par où
commencent les données. Il peut varier de 5 (soit 20 octets d’en-tête) à 15 (60 octets d’en-
tête).
 TOS : Type of Service (8bits) indique la qualité du service demandé pour ce datagramme où
les 8 bits sont décomposés comme suit :

Figure A3.02 : Format du TOS IP

80
 - Priorité : codée sur 3 bits. Elle indique la priorité voulue pour le datagramme. La priorité
augmente avec la valeur de ce champ. Les valeurs possibles sont les suivantes :
000 : Routine ;
001: Priority ;
010 : Immediate ;
011 : Flash ;
100 : Flash Override ;
101 : Critic ;
110 : InterNetwork Control ;
111 : Network Control.

- bit D (Delay) : à 1, indique l’acheminement du datagramme doit privilégier le délai (il doit
arriver le plus rapidement possible).
- bit T (Throuhput) : à 1, indique que le datagramme fait partie d’une communication qui a
besoin d’un gros débit.
- bit R (Realibilty) : à 1, indique qu’il faut privilégier la fiabilité : un effort particulier doit
être fait pour acheminer correctement ce datagramme, notamment en empruntant autant
que possible des réseaux à faible taux d’erreur.
- bits inutilisés : doivent être à 0.
 Longueur Totale : (16 bits) donne la taille totale en octets du datagramme.
 Identification : (16 bits) c’est un numéro identifiant le datagramme de façon non ambiguë par
rapport à sa source. Il permet de rassembler les fragments d’un même datagramme afin de le
reconstituer.
 Flags : Indicateurs de fragmentation (3bits).

Figure A3.03 : Format des Flags IP

- bit 0 : bit inutilisé et à 0

81
 - bit don’t Fragment : si positionné à 1, indique que ce datagramme ne doit pas être
fragmenté, dans ce cas, un routeur qui n’a d’autre choix que le fragmenter va le détruire et
enverra un message ICMP de compte rendu de destination inaccessible.
- bit More : si positionné à 1, indique que le datagramme n’est qu’une partie du datagramme
d’origine et que ce n’est pas le dernier fragment. Si à 0, indique que le datagramme est le
dernier fragment du datagramme d’origine. On reconnaît un datagramme non fragmenté
lorsque le bit More est à 0 et que le Déplacement est aussi à 0.
 Déplacement : offset (13bits) ce champ sert pour la fragmentation. En multipliant sa valeur par
8, on obtient la position dans le datagramme d’origine du premier octet de données de ce
datagramme.
 TTL : Time to Live (8 bits) valeur fixant la durée de vie en secondes du datagramme.
 Protocol : (8 bits) ce champ sert au démultiplexage car il indique à quel protocole il faut
remettre les données transportées dans le datagramme.
- 0 : IP
- 1 : ICMP
- 6 : TCP
- 17 : UDP
 Checksum : contrôle de l’en-tête (16 bits) permet de contrôler l’intégrité de l’en-tête.
 Option : (taille variable, pouvant être nulle) ce champ comprend la découverte du MTU,
l’enregistrement d’une route suivie par un datagramme, le routage à la source, etc.

82
 ANNEXE 4 : CRITERE DE MOS

La caractérisation de la qualité du service dans les réseaux IP est généralement traduite par le
paramètre qualitatif. Un des paramètres qualitatifs est le critère de MOS. Ce paramètre est issu de
la recommandation P 800.1 de l’UIT. C’est une méthode qui consiste à fournir une note subjective
de 1 à 5 (5 étant la valeur la plus favorable) représentative de la qualité de service perçue par un
utilisateur moyen. Le MOS est calculé à partir de la formule suivante :

𝑑 𝑏𝑖𝑡 𝑢𝑡𝑖𝑙𝑠𝑒 𝑚𝑜𝑦𝑒𝑛

𝑀𝑜𝑠 = (A4.1)
𝑡𝑒𝑚𝑝𝑠 𝑑𝑒 𝑡𝑟𝑎𝑛𝑠𝑓𝑒𝑟𝑡

Le tableau fait correspondre la valeur du MOS au niveau de la qualité perçue :

MOS Niveau de QoS

5 Excellent
4 Bon
3 Moyen
2 Dégradé
1 Mauvais

Tableau A4.01 : Correspondance entre MOS et QoS

83
 ANNEXE 5 CONFIGURATION DES ROUTEURS AVEC GNS3

A5.1 Routeur Site1_PE :

#création d’un VPN

ip vrf Voice
rd 65:1
route-target export 65:1
route-target import 65:1
#définition du protocole BGP
bgp next-hop Loopback100
#définition de l’interface loopback
interface Loopback100
description ***** BGP NEXT-HOP POUR Client******
ip address 100.100.100.100 255.255.255.255
!
mpls traffic-eng tunnels
!
#création d’un tunnel pour transporter la voix
interface Tunnel10
description ***** MPLS TE client******
ip unnumbered Loopback10
mpls ip
tunnel destination 192.0.26.1
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng priority 1 1
tunnel mpls traffic-eng bandwidth 2000
tunnel mpls traffic-eng path-option 1 dynamic
no routing dynamic
#route static dans le tunnel
ip route 60.60.60.60 255.255.255.255 Tunnel10

84
A5.2 Routeur Site3_PE

#créationd’un clock pour la synchronisation

clock timezone utc 5 30
ntp master clock set 4:11:00 8 july 2014
#définition de la téléphonie service
telephony-service
max-ephone 2
max-dn 20
ip source-address 10.10.30.1
auto assig 1 to 2 type cipc
creat cnf-files
!
line console 0
logging synchronous
no exec-timeout
login local
!
line vty 0 903 logging synchronous
no exec-timeout
login local
!
#Définition d’un client
ephone-dn 1 dual-line
number 100
label Arnaud
ephone 1
button 1:1
description arnaud
restart
dial-peer voice 1 voip
destination-pattern 2..
session target ipv4:10.250.20.1

85
 BIBLIOGRAPHIE

[1] T. H. Andriamialison, “La Voix sur IP”, Mémoire de fin d’études, Dép.Tél. - ESPA,
A.U. : 2000-2001
[2] Go. Tiers,” Voix sur IP”, Lannemezan, 2005

[3] F. Nicolas, “Sécurité de la Voix sur IP”, 2013

[4] O. Hersent, D. Gurle, J.P. Petit, “La Voix sur IP”, Dunod : Paris 2006

[5] A. Sulkin, “PBX Systems for IP Telephony”, McGraw-Hill Telecom : USA 2002

[6] ITU-T, “An architectural framework for support of Quality of Service (QoS) in Packet networks”,
Recommendation Y.1291

[7] F. Lemainque, “Tout sur les réseaux sans fil”, Dunod, 2009

[8] J. Mélin, “Qualité de service sur IP”, Eyrolles, 2001

[9] J. Montagnon, T. Huaong, “MPLS et les réseaux d’entreprise”, 2002

[10] E. Osborne, A. Simha, “Traffic Engineering with MPLS”, Cisco Press, 2002

[11] P. Brittain, A. Farrel, “MPLS Traffic Engineering: a choice of signaling protocols”, 2000

[12] J. Uzé, “VPLS: Virtual Private LAN Service”, Juniper Networks, 2013

[13] http://www.frameip.com/mpls/index.html

[14] A. R. Mohamed, “Optimisation des ressources hétérogènes avec Coeur de réseau MPLS”, l’Institut
National des Sciences Appliquées de Toulouse, 2007

[15] A. A. Randriamitantsoa, “Planification, Modelisation et Simulation des réseaux par le protocole

MPLS”, Mémoire de fin d’études, Dép.Tél. - ESPA, A.U. : 2000-2001

[16] M. Schwartz, “Telecommunication Networks-Protocols, Modeling and Analysis”, Addision-Wesley

Publishing Company, 1987

[17] L. Toutain, “Réseaux locaux et Internet”, Hernès, 2ème edition, 1999

[18] UIT, “Planitu, Introduction à la théorie de base de télétrafic”, Planitu, Doc 19, 2000

[19] UIT, “Réseaux IP, tarification des services des telecommunications”, rapport final, Janvier 2003

[20] M. Becker, A.-L. Beylot, “Simulations des réseaux”, Lavoisier, 2006

86
[21] D. Ros, R.Marie, “Los characterization in high speed networks through simulation of fuild
models”, Telecommunication Systems, Février 2001.

[22] http://www.opnet.com

[23] http://www.opnet.com/university_program/teaching_with_opnet/textbooks_and_materials/materials

87
 PAGE DE RENSEIGNEMENT

Nom : RAVOAVAHY

Prénoms : Andriamparany Arnaud

Adresse : Lot IIL 37 Ankadivato

Antananarivo 101
MADAGASCAR
Tel : +261 33 61 525 43
E-Mail: pax10telecom@yahoo.com

Titre du mémoire :

« ANALYSE DE PERFORMANCE DE LA VOIP SUR UN BACKBONE MPLS AVEC

TRAFFIC ENGINEERING »

Nombre de pages : 79

Nombre de tableaux : 6

Nombre de figures : 51

Mots clés : VoIP, MPLS, TE, BGP, OPNET Modeler, GNS3

Directeur de mémoire :

Nom : RAVONIMANANTSOA

Prénoms : Ndaohialy Manda-Vy

Grade : Maître de conferences

Tel : +261 33 12 358 00

E-mail : ndaohialy@gmail.com

88
 RESUME

La voix sur IP acquiert de plus en plus d’importance dans le domaine des télécommunications,
surtout pour les entreprises, grâce à ses avantages économiques et techniques. Avec
l’augmentation des applications envoyées sur les réseaux IP, et afin de fournir un service fiable, il
faudrait utiliser des mécanismes assurant cette qualité comme la technologie MPLS. Nous avons
montré que l’utilisation de ce mécanisme dans le Backbone assure une bonne qualité des
paramètres tels que le délai de transmission, la perte de paquet et la gigue. En effet, MPLS n’offre
pas seulement une vitesse de commutation considérable par rapport aux autres protocoles mais
aussi permet l’équilibrage de charge dans le réseau avec « le traffic Engineering » qui est une
technique impossible à réaliser dans les autres protocoles de routage IP.

ABSTRACT

VoIP becomes more and more important in telecommunications, especially for enterprise, thanks
to its economic and technical advantages. With the increase in applications sent over IP networks
and to provide a reliable service should be used mechanisms to ensure the quality as MPLS. Its
use in the Backbone provides good quality parameters such as transmission delay, packet loss and
jitter. Indeed MPLS, not only provides a considerable speed switching compared to other
protocols but also, allows load balancing in the network with the traffic Engineering which is
impossible to be realized in other IP routing protocols .

89