Rapport Projet Dev

Mini projet développement INE2
Projet développement
Réalisation d’un outil de gestion de QoS avec le

protocole MPLS et routeur virtuel dans un réseau
IMS
Réalisé par : Encadré par :
Kaoutar TEBBAA Mr M.BELLEFKIH

Soufiane TAZARINE
Page 1
Remerciement
Cette page répond à une exigence morale bien plus

qu’à l’habituel souci d’honnêteté formelle. En effet, il serait difficile d’établir
une liste exhaustive des personnes ayant, d’une façon ou d’une autre, permis la
réalisation de ce rapport.
L’absence d’une référence explicite à chacun d’entre
eux ne saurait, en aucun cas, être interprétée comme un manque de
reconnaissance.
Cependant, nous tenons nommément à remercier
Mr M.BELLEFKIH pour ses idées originales qui ont grandement contribué à
l’enrichissement de notre formation.
Aussi, nous tenons à remercier Mr BELMEKKI et Mr BRAHIM
pour avoir partagé leur expérience avec nous, ainsi que pour leur précieux
soutien.
Merci
Page 2
Introduction
Avec l'avènement du mobile, l'explosion des accès ADSL ou encore l'usage désormais très
répandu de la voix sur IP, le secteur des télécommunications subit un ensemble de changements profonds.
Dans ce contexte de convergence télécoms/informatique, de puissance de terminaux et d'hétérogénéité des
réseaux d'accès et avec une évolution générale vers le monde IP, des solutions doivent être apportées.
Pour répondre à ces nouveaux besoins, plusieurs opérateurs ont choisi de déployer l'IMS (IP Multimedia
Subsystem) sur l'ensemble de leur réseau. Il s'agit de la seule architecture de référence de réseau télécoms
convergent fixe/mobile actuellement normalisée.
Pour cela, nous avons choisi comme projet d’étudier l’architecture IMS afin de réaliser un
outil de gestion de QoS avec le protocole MPLS et routeur virtuel dans un réseau IMS.
Page 3
SOMMAIRE
CHAPITRE I : IP Multimedia Subsystem (IMS)
1- Définition.....................................................................................................................................4
1- La vision de l'IMS........................................................................................................................4
2- Pourquoi l'IMS?..........................................................................................................................5
3- Standardisation de l'IMS.............................................................................................................6
4- Les objectifs fondamentaux de l'IMS.........................................................................................7
5- Les Protocoles de l'IMS..............................................................................................................9
6- Architecture IMS......................................................................................................................11
7- Points forts et points faibles de l’IMS.....................................................................................12
CHAPITRE II : Les concepts de base de MPLS

1- Introduction à MPLS...............................................................................................................14
2- Architecture du MPLS.............................................................................................................17
3- Allocation et diffusion des labels............................................................................................17
4- Les modes de MPLS................................................................................................................22
CHAPITRE III : Implémentation d’un réseau MPLS sous GNS 3

1- Introduction.............................................................................................................................30
2- Outil de simulation GNS3.......................................................................................................30
3- Mise en place du protocole Ldp au backbone........................................................................33
4- Configuration de mpls............................................................................................................34
CHAPITRE IV : Simulation
1- Introduction.............................................................................................................................39
2- Architecture ............................................................................................................................39
3- Configuration des routeurs …………………………............................................................40
4- Configuration des machines (client IMS et serveur IMS).....................................................42
5- Test de l’architecture MPLS-IMS avec des pings..................................................................47
6- Lancement des services IMS ..................................................................................................48
7- Test de la qualité de service IMS gérée avec BEST EFFORT.............................................51
8- Configuration des routeurs avec DIFFSEFV.......................................................................52
9- Test de l’Amélioration de la qualité de service avec DIFFSERV........................................61
Liste des figures...................................................................................................................
Page 4
CHAPITRE I :
IP Multimedia Subsystem
Page 5
1- Définition :
L'IMS (IP Multimedia Subsystem) est la technologie qui va combiner Internet et le monde
cellulaire. Il permettra aux applications internet comme la messagerie électronique (email), la messagerie
instantanée, le service de présence ou encore la vidéoconférence, d'être accessible presque partout.
La vitesse à laquelle les technologies IMS ont été développées ces dernières années est
impressionnante et l’IMS supporte de nos jours un large panel de nouveaux services. Mais avant d'entrer
dans le vif du sujet et de détailler comment fonctionne l'IMS, nous allons d'abord poser un certain nombre
de questions et y apporter quelques éléments de réponses. Dans ce qui suit, nous allons présenter ce qu'est
l'IMS, pourquoi il a été créé, qu'apporte l'IMS et quelles sont les organisations impliquées dans sa
standardisation.
2- La vision de l'IMS :
Les réseaux de troisième génération (3G) ont pour but de combiner les deux plus grands
succès en matière de communication, à savoir les réseaux cellulaires et Internet. L'IP Multimedia
Sybsystem est l'élément principal de l'architecture 3G qui permet un accès global à tous les services que
propose Internet et ce indépendamment du lieu. Imaginez-vous en train d'accéder à vos emails, prendre
part à une vidéo conférence ou encore naviguer sur vos sites web favoris tout cela en sortant un terminal
3G de votre poche. Telle est la vision promue par l'IMS.
Internet
Internet a connu un succès phénoménal ces dernières années. Il a évolué d'un petit réseau reliant
quelques sites de recherche vers un réseau mondial. La raison principale de cette évolution est la capacité
à offrir des services très utiles aux utilisateurs. Les exemples les plus connus de ces services étant le
World Wide Web et la messagerie électronique ; mais il existe cependant plusieurs autres tels que la
messagerie instantanée, la présence, la Voix sur IP ou la vidéo conférence. Internet est capable de
proposer tous ces nouveaux services car il utilise des protocoles ouverts disponibles sur le web pour tout
développeur de services. En plus, les outils nécessaires au développement de nouveaux services sont
enseignés dans les universités et sont expliqués dans plusieurs livres.
Le monde cellulaire
Présentement, les réseaux téléphoniques cellulaires offrent des services à plusieurs millions
d'utilisateurs à travers le monde. Ces services incluent évidemment les appels téléphoniques mais ne se
limitent pas seulement à cela. Les réseaux cellulaires modernes offrent des services de messagerie allant
du simple message (SMS) aux messages multimédias qui incluent la vidéo, l'audio et le texte (MMS). Les
utilisateurs de ses réseaux sont capables de se connecter sur Internet et certains opérateurs offrent même
le service de localisation pour notifier à un utilisateur qu'un collègue est à côté.
Page 6
Cependant les réseaux cellulaires n'ont pas beaucoup attiré à travers les services qu'ils offrent. Leur
point fort est que les utilisateurs sont couverts pratiquement partout, non seulement dans les villes mais
aussi dans les campagnes et même pendant les déplacements dans d'autres pays (accords de roaming entre
opérateurs).
3- Pourquoi l'IMS ?
D'un côté nous avons mentionné que l'idée derrière l'IMS est d'offrir les services Internet partout
et à tout moment en utilisant les réseaux cellulaires. D'autre part nous avons aussi mentionné que les
réseaux cellulaires offrent déjà plusieurs services populaires sur Internet tel que la messagerie instantanée.
En fait, tout utilisateur d'un réseau cellulaire peut accéder à Internet en utilisant une connexion par paquet
et ce faisant il peut bénéficier des services offerts par Internet. Alors, pourquoi avons-nous besoin de
l'IMS ? La réponse à cette question est triple : la qualité de service (QoS), la facturation et l'intégration de
différents services.
Le problème principal de la commutation de paquet est qu'il fournit les services multimédia
temps réel à la manière « best effort » c'est à dire sans qualité de service (le réseau n'offre aucune garantie
quant à la bande passante allouée ni le retard que peut prendre les paquets). Donc, la qualité des
conversations VoIP peut se dégrader de façon dramatique. D'un moment à l'autre, la voix d'un des
correspondants peut être inaudible. Maintenir une bonne qualité de service durant une conversation peut
ainsi être un vrai cauchemar. Ainsi, une des raisons pour lesquelles l'IMS a été créé est de permettre de
profiter des sessions multimédia temps réel et non de les souffrir.
La seconde raison ayant poussé à la création de l'IMS est de permettre de facturer les sessions
multimédia de façon plus efficace et plus appropriée. Par exemple, un utilisateur participant à une vidéo
conférence transfert une grande quantité d'information (qui consiste principalement en des données audio
et vidéo encodées). En fonction de l'opérateur 3G fournissant le service, le transfert d'une telle quantité de
données peut s'avérer être très coûteux pour l'utilisateur vu que l'opérateur facture en fonction de la taille
des données transférées (l'opérateur ne fait pas de différence qu'il s'agisse de données VoIP, de la
messagerie instantanée, de la navigation sur Internet, etc.). Donc si l'opérateur connaît le type de service
invoqué par l'utilisateur, il pourrait lui proposer un système de facturation plus souple et moins coûteux.
Par exemple, l'opérateur pourrait facturer une session multimédia selon la durée de la session
indépendamment de la taille des données transférées. L'IMS n'impose aucun un modèle de business à
l'opérateur mais le laisse facturer comme bon lui semble. L'IMS fournit des informations sur le service
demandé par l'utilisateur et c'est à l'opérateur de décider comment facturer le service.
Fournir des services intégrés est la troisième raison pour l'IMS. Les opérateurs veulent pouvoir
utiliser des services développés par différentes parties tierces, de les combiner, de les intégrer avec les
services déjà existants et de fournir ainsi aux usagers un tout nouveau service. Par exemple, un opérateur
fournit le service de boîte vocale et une partie tierce a développé un service de conversion texte-audio. Si
l'opérateur achète le service de cette partie tierce, il peut proposer de convertir les messages textuels en
messages vocaux pour les usagers mal voyant. L'IMS définit les interfaces standards pour développer des
Page 7
services. Ainsi, les opérateurs ont la possibilité d'utiliser toute l'industrie de création de services au lieu de
se confiner à un seul fournisseur.
En outre, le but de l'IMS n'est pas seulement d'offrir de nouveaux services mais il s’agit aussi de
supporter tous les services, présents et futurs, qu’Internet offre. En plus, les utilisateurs doivent avoir la
possibilité d'utiliser leurs services non seulement dans leur réseau d'opérateur mais aussi lorsqu'ils sont en
déplacement dans d'autres réseaux. Pour y arriver, l'IMS utilise les technologies et protocoles Internet.
Ainsi, une session multimédia entre deux usagers IMS, entre un usager IMS et un usager
Internet, ou entre deux usagers Internet, est établie en utilisant exactement le même protocole. En plus, les
interfaces fournis aux développeurs mentionnées plus haut utilisent les protocoles Internet. Telle est la
manière avec laquelle l'IMS combine le monde cellulaire et Internet : il utilise les technologies cellulaires
pour offrir une couverture et un accès globaux et Internet pour offrir des services.
4- Standardisation de l'IMS :
Comme cela a été dit précédemment, l'IMS utilise les protocoles Internet. Lorsque l'IMS a
besoin d'un protocole particulier (par exemple pour l'établissement d'une session multimédia), les
organismes de standardisation de l'IMS choisissent le protocole Internet dédié à cette tâche et spécifient
son utilisation par l'IMS.
La normalisation de l’IMS est assurée par trois organismes principaux que sont l’IETF, le 3GPP
ainsi que l’ETSI à travers le groupe spécialisé TISPAN.
L’IETF
L’IETF définit et promeut les standards du monde Internet en collaboration avec le W3C et l’ISO.
L’IETF s’occupe particulièrement des protocoles de la pile TCP/IP (Transmission Control
Protocol/Internet Protocol). C’est un organisme ouvert composé de personnes volontaires et qui n’impose
aucune contrainte : toute personne physique ou morale peut participer à l’effort de normalisation.
SIP, protocole le plus important de l’architecture IMS est un standard de l’IETF. Le groupe de
travail sur SIP au sein de l’IETF assure le développement et la pérennité du protocole SIP (définit dans la
RFC 3261) et de ses extensions. Pour plus d'informations sur l'IETF, visiter leur page web: www.ietf.org.
Le 3GPP
Le 3GPP (www.3gpp.org) est né en 1998 grâce à un accord de collaboration entre différents
organismes de normalisation régionaux dont l'ARIB du Japon, le CCSA de la Chine et l'ETSI. A
l'origine, le 3GPP avait pour but de développer les spécifications et rapports techniques d'un réseau
mobile de troisième génération basé sur le GSM. Aujourd'hui, le 3GPP s'occupe aussi du développement
et de la maintenance des spécifications du GSM.
TISPAN
TISPAN (http://etsi.org/tispan) est un groupe de travail de l'ETSI spécialisé dans la convergence
entre les réseaux fixes (tel que le RTC) et Internet. TISPAN s'occupe de la définition européenne des
Page 8
réseaux de nouvelle génération même s'il comprend des membres venant d'autres régions autre que
l'Europe.
5- Les objectifs fondamentaux de l'IMS :
L'IMS se propose de :
• Combiner les dernières tendances technologiques

• Transformer le concept d'internet mobile en réalité
• Créer une plateforme commune de développement de nouveaux services
• Créer un mécanisme pour booster les marges dues à l'utilisation additionnelle des réseaux mobiles
paquet
À présent, voyons les besoins qui ont motivé la mise en place de l'IMS. Dans ses spécifications,
l'IMS est défini comme une architecture créée dans le but de délivrer des services IP multimédia aux
utilisateurs. Cette architecture doit:
1. Supporter l'établissement des sessions multimédia IP

2. Permettre de négocier la qualité de service (QoS)
3. S’interconnecter avec Internet ainsi que les réseaux à commutation de circuit
4. Supporter le roaming
5. Permettre à l'opérateur de contrôler les services fournis aux usagers
6. Permettre la création rapide de nouveaux services sans standardisation
La Release 6 du 3GPP (TS 22 228) a ajouté le support d'autres réseaux d'accès à part le GPRS. C'est pour
cela qu’on parle de l'indépendance de l'IMS par rapport au réseau d'accès.
Les sessions multimédia IP

L'IMS permet d'offrir beaucoup de services. Cependant, un service très important concerne les
communications audio et vidéo. Cette spécification met l'accent sur le service principal que doit offrir
l'IMS : les sessions multimédia sur le réseau de commutation de paquet. En effet, les communications
multimédia étaient déjà standardisées par le 3GPP mais cela concernait les réseaux à commutation de
circuit.
La qualité de service
Il s'agit d'un élément clé dans l'IMS. L'IMS doit permettre aux opérateurs de contrôler la qualité de
service offerte aux usagers et ainsi de différencier différents groupes d'utilisateurs.
L'interconnexion
L'interconnexion avec Internet est un besoin évident vu qu’Internet offre des millions de
destinations aux sessions multimédia initiées depuis l'IMS, ce qui augmente considérablement les
potentielles sources et destinations des sessions multimédia. L'IMS doit aussi supporter l'interconnexion
avec les réseaux à commutation de circuit tel que le RTC ou les réseaux cellulaires existants.
Le roaming
Le support du roaming est fondamental depuis l'avènement des réseaux cellulaires de seconde
génération: les utilisateurs doivent pouvoir se déplacer dans différents réseaux. L'IMS a hérité de cela,
Page 9
permettant ainsi aux utilisateurs de voyager dans d'autres pays (sous condition d'existence d'accord de
roaming entre les opérateurs).
Le contrôle de service
Les opérateurs ont besoin d'imposer des règles sur les services fournis aux usagers. On peut classer
ces règles en deux catégories :
• des règles générales qui s'appliquent à tous les usagers

• des règles individuelles s'appliquant au cas par cas
La première catégorie de règles comprend un ensemble de règles s'appliquant à tous les utilisateurs
du réseau. Par exemple les opérateurs peuvent interdire l'utilisation des codecs audio gourmands en bande
passante (comme le G 711) et promouvoir l'utilisation des codecs bas débit tel que l'AMR (spécifié dans
le 3GPP TS 26 071). La seconde catégorie de règles comprend des règles propres à chaque utilisateur. Par
exemple, si l'abonnement d'un utilisateur ne comprend pas l'utilisation de la vidéo, même si le terminal
IMS est capable de gérer la vidéo, l'opérateur va empêcher l'ouverture de sessions multimédia nécessitant
la vidéo.
La création rapide des services

Les services IMS ne doivent pas être standardisés. Cela représente une grande évolution dans les
réseaux cellulaires car dans le passé chaque service était soit standardisé, soit propriétaire et même
lorsqu'il était standardisé il n'y avait aucune garantie concernant son fonctionnement en dehors du réseau
de l'opérateur. L'IMS se propose de réduire le temps de mise en place des nouveaux services en
standardisant non pas le service mais les capacités du service.
L'accès multiple
Il s'agit de supporter d'autres réseaux d'accès en plus du GPRS. En effet, l'IMS n'étant qu'un réseau
IP, il doit être indépendant du réseau d'accès. Tout réseau doit pouvoir accéder à l'IMS, par exemple les
réseaux WLAN, ADSL ou le modem.
Page 10
Figure 1: IMS et les NGN
6- Les protocoles de l'IMS :
Lorsque le 3GPP a commencé à développer l'IMS, un système basé sur les protocoles IP (sont
généralement développés par l'IETF), il s'est appuyé sur le travail déjà accompli par l'IETF et l'ITU-T
réduisant ainsi le temps et le coût de développement.
Contrôle de la session : SIP

Le protocole qui contrôle les appels joue un rôle très important dans tout système de téléphonie.
Spécifié par l'IETF comme protocole pour l'établissement et la gestion de sessions multimédia sur
les réseaux IP, SIP était très célèbre lors du choix du protocole de signalisation par le 3GPP. SIP (RFC
3261) utilise le modèle client/serveur comme c'est le cas de la plupart des protocoles développés par
l'IETF. Les principes de SIP ont été empruntés de SMTP (RFC 2821) et plus particulièrement de HTTP
(RFC 2616). SIP a ainsi hérité des deux protocoles les plus célèbres du monde Internet. Contrairement à
BICC et H323, SIP ne fait pas de différence entre les connexions Hôte-Réseau (UNI : User to Network
Interface) et Réseau-Réseau (NNI : Network to Network Interface). SIP est aussi un protocole textuel ce
qui facilite son extension, le débogage et la création des services (SIP étant basé sur HTTP, les
développeurs de services peuvent utiliser toute la puissance de l'architecture HTTP comme les CGI ou
encore les Servlets Java).
SIP a été choisi comme protocole pour le contrôle de la session dans l'IMS et le fait que SIP facilite
le développement de services a joué un grand rôle dans le choix du 3GPP. Une présentation du protocole
SIP se trouve en Annexe A.
Page 11
Autorisation/Authentification/Accounting : Diameter
En plus du protocole de gestion de la session, il existe d'autres protocoles qui jouent un rôle
significatif dans l'IMS. Diameter (RFC 3588) a été choisi comme protocole AAA dans l'IMS. Diameter
est une évolution du protocole RADIUS (RFC 2865) qui est un protocole très utilisé sur Internet pour
faire l’AAA. Diameter consiste en un protocole de base auquel on ajoute ce que l'on appelle les
applications Diameter. Les applications Diameter sont des extensions ou des implémentations spécifiques
de Diameter pour une application particulière dans un environnement donné.
L'IMS utilise Diameter dans un certain nombre d'interfaces bien que toutes les interfaces n'utilisent
pas forcément la même application Diameter.
- Autres protocoles
En plus de Diameter et de SIP, l'IMS utilise d'autres protocoles :
• SDP (RFC 4566) est utilisé pour initialiser ou modifier les paramètres media utilisés par la
session.
• COPS (RFC 2748) est utilisé pour le transfert des politiques entre les PDP et les PEP.
• H.248 est utilisé par les nœuds de signalisation pour contrôler les nœuds situés dans le plan media
(exemple le media gateway controller qui contrôle le media gateway). H.248 a été développé par
l'ITU-T et l'IETF et porte le nom de MEGACO.
• RTP (RFC 3550) et RTCP (RFC 3550) sont utilisés pour transporter les medias temps réel comme
l'audio ou la vidéo
Figure 2 : Protocoles IMS
Page 12
7- Architecture IMS :
Avant de détailler l'architecture IMS, nous devons garder à l'esprit que le 3GPP ne définit pas
les nœuds mais plutôt les fonctions. Cela veut dire que l'architecture de l'IMS est constituée d'un ensemble
de fonctions reliées entre elles par des interfaces standardisées. Les implémentations peuvent soit
combiner deux fonctions dans une même entité physique soit séparer une même fonction en deux entités
différentes. La figure suivante montre l'architecture générale du cœur de réseau IMS. Il inclut les nœuds
suivants :
• une ou plusieurs bases de données, appelées HSS ou SLF

• un ou plusieurs serveurs SIP connus sous le nom global de CSCF
• un ou plusieurs serveurs d'applications
• un ou plusieurs MRF, divisé chacun en un MRFC et un MRFP
• un ou plusieurs BGCF
• une ou plusieurs passerelles vers le RTC, décomposée chacune en un SGW, un MGCF et un
MGW.
Figure 3 : Architecture IMS
Page 13
8- Points forts et points faibles de l'IMS :
- Points forts :
L'IMS permet de disposer d'une plateforme unique capable de gérer un grand nombre d'applications
multimédia (dont la voix sur IP) avec une très bonne qualité de service sur les réseaux de circuits et de
paquets, et entre réseaux fixes et mobiles. D'après les mises en œuvre déjà réalisées, il semble que l'IMS
soit rentable à partir de plusieurs applications cibles justifiées commercialement. Les exemples montrés
sont spectaculaires (See What I See, les jeux, le PTT, l'échange d'images fixes ou d'images d'écran, etc.).
L'IMS est un Internet amélioré qui permet la convergence de réseaux associés. L'exploitant peut faire
payer la qualité de service et la sécurité à son prix réel. Il contrôle mieux le réseau. La construction de
nouvelles applications est facile et immédiate.
L'IMS assure l'authentification mutuelle des deux parties (le client et le réseau). Ses coûts en OPEX et
CAPEX en feraient un outil très compétitif, si les marchés répondent favorablement. La nécessité du
rajeunissement du réseau historique est liée à une prise de décisions en accord avec les autres exploitants.
L'IMS est la seule solution possible pour renouveler des équipements de réseau qui arrivent en fin
d'amortissement et qui ne sont pas en mesure d'offrir des services multimédia avancées.
- Points faibles :
Le nombre de profils d'usagers et d'applications à définir laisse sceptiques les décideurs. La voix
sera-t-elle encore longtemps le service majeur dans les dix ans à venir ? Le passage en IPv6 représente un
coût important pour un bénéfice qui ne semble pas évident.
Il faut parvenir à créer des applications qui ne nécessitent pas des manipulations complexes sur les
claviers des terminaux.
Il faut s'assurer de la sécurité des interactions entre équipements de signalisation et de l'inviolabilité

de celles-ci. L'IMS, résultant de la conjonction d'un grand nombre d'éléments à intégrer, suscite des
inquiétudes quant aux coûts et à la fiabilité globale.
Il faudrait disposer de plus grandes certitudes sur la croissance du trafic téléphonique vocal. La
centralisation des fonctions de transit sur une dizaine ou une vingtaine de commutateurs par logiciel en IP
fragiliserait le réseau.
L'adaptation de l'IMS à l'accès fixe est coûteuse. La proportion d'abonnés qui est concernée par les
nouvelles applications technologiques ne peut pas être évaluée avec précision. L'abonné est-il prêt à
abandonner le forfait pour la tarification au service utilisé ?
Page 14
CHAPITRE II :
Les concepts de base de MPLS
Page 15
1- Introduction à MPLS :
1.1- Le Routage IP classique :
IP est un protocole de niveau réseau fonctionnant dans un mode non connecté, c'est-à-dire que
l'ensemble des paquets (ou datagrammes) constituant le message sont indépendants les uns des autres : les
paquets d'un même message peuvent donc emprunter des chemins différents utilisant des protocoles IGP
(Interior Gateway Protocol), ou bien des protocoles EGP (Exterior Gateway Protocol). Chaque routeur
maintient une table de routage, dans laquelle chaque ligne contient un réseau de destination, un port de
sortie, et le prochain routeur relaie vers ce réseau de destination.
A la réception d'un datagramme, les noeuds intermédiaires (ou routeurs) déterminent le prochain
relais (ou next-hop) le plus approprié pour que le paquet rallie sa destination. Ensuite l'adresse mac
destination (niveau 2 du model OSI) du datagramme est remplacée par l'adresse mac du routeur relais, et
l'adresse mac source du datagramme est remplacée par l'adresse mac du routeur courant, laissant sans
changement les adresses IP (niveau 3 du model OSI) du datagramme afin que le prochain routeur effectue
les même opérations sur le paquet pour les sauts suivants. Ce calcul fastidieux est effectué sur tous les
datagrammes d'un même flux, et cela autant de fois qu'il y a de routeurs intermédiaires à traverser. Il est
donc gourmand en terme de ressource machine. Le mode non connecté du protocole IP, qui était
initialement l'un de ses atouts, en particulier pour sa scalabilité, est devenu aujourd'hui un frein à son
évolution.
Figure 4 : Routage IP
Autre inconvénient du routage IP réside dans la surcharge des chemins de bande passante élevée,
causant ainsi des engorgements et laissant d’autre chemins inexploitables et ainsi, mauvaise gestion des
ressources du réseau.
Page 16
Figure 5 : Gestion du réseau IP
1.2- La Commutation ATM :
La commutation ATM fonctionne en deux phases :

- Le bloc d’appel du flux est routé en analysant son adresse de destination (adresse X25 par exemple). La
route empruntée est mémorisée et associée à des numéros de voie logique (NVL) dans chacun des
équipements traversés.
- Les blocs de données du flux sont commutés en fonction du NVL auquel ils sont associés. En traversant
un équipement, le NVL du bloc de données est remplacé par le NVL de l’équipement suivant. En ATM
l’ensemble des bonds effectués est appelé « Circuit Virtuel ». Chaque circuit virtuel peut être lié à une
qualité de service.
Mais l’acheminement des données ne se fait pas d’une manière intelligente.
Les Switchs ATM n’ont aucun détail sur les informations de la couche 3 et transmettent les données
de façon non optimale.
La figure si dessous, montre que pour atteindre le réseau 10.1.1.1, la trame doit passer par 7 hops,
alors qu’il y a un chemin plus optimal, empruntant juste deux hop.
Figure 6 : Commutation sur ATM
Page 17
1.3- Principe de MPLS :
C’est donc dans ce cadre qu’est apparu le MPLS (Multi-Protocol Label

Switching), destiné à intégrer les avantages de l’IP et les avantages d’une
technologie en mode circuit comme l’ATM (circuits virtuels), afin de répondre
aux besoins de fiabilité et de disponibilité. Le MPLS a été conçu pour transporter des paquets IP, en leur
attribuant des numéros d’identification particulièrement courts et faciles à traiter appelés étiquettes
(label).
Figure 7 : les Couches MPLS
Avec MPLS, on a voulu augmenter les fonctionnalités de l’architecture conventionnelle du routage

IP. Les intérêts majeurs de MPLS résident donc dans la flexibilité du routage lié au Traffic Engineering,
la puissance de commutation, la mise en place d’une certaine Qualité de Service (QoS) et les VPN
(Virtual Private Networks).
Page 18
2- Architecture du MPLS :
Un domaine MPLS est composé de deux sortes de routeurs, les LSR (Label Switching
Router) et les ELSR (Edge Label Switching Router). Les LSR sont les routeurs de cœur capables de
supporter le MPLS et les ELSR sont des routeurs permettant de faire la transition entre le domaine MPLS
et les autres réseaux, par exemple, les clients IP.
Le schéma suivant montre le rôle des différents routeurs en fonction de leur emplacement dans le réseau
MPLS :
Figure 8 : Routeurs MPLS
3- Allocation et diffusion des labels :
3.1- Format du label MPLS :
Le MPLS utilise un label de 32 bits contenant les informations suivantes :
Figure 9 : Etiquette MPLS (Label)
20 bits contiennent le label,
Page 19
un champ de 3 bits appelé Classe of Service (CoS) sert actuellement pour la QoS,
un bit S pour indiquer s'il y a empilement de labels,
un dernier champ, le TTL sur 8 bits (même signification que pour IP)
Le MPLS a deux façons de réaliser ce transport :
Dans le cas du circuit ATM, le label sera transporté dans le champ VPI/VCI du header, c’est ce qu’on
appelle le Cell Mode.
Figure 10 : Label en Cell Mode
Le label sera transporté dans le " Shim " label header qui sera inséré entre le header de la couche
liaison et le header de la couche réseau.
Cette technique permet de supporter la technique du label switching sur n’importe quel protocole de
la couche liaison. Nous appelons ce mode Frame Mode.
Figure 11 : Label en Frame Mode
3.2- Les équipements MPLS :
Pour être en mesure de procéder au traitement de ce label, MPLS se base sur l’utilisation de
deux principales familles d’équipements à savoir :
Label Switch Router (LSR) : qui est un équipement de type routeur ou commutateur capable de
commuter des paquets ou des cellules, en fonction de la valeur des labels qu’ils contiennent. Dans le cœur
du réseau, les LSRs procèdent tout simplement à la lecture et la commutation des labels, et non les
Page 20
adresses des protocoles de niveau supérieur. Chaque LSR construit une table FIB ( Forwarding
Information base).
Edge Label Switch Router (ELSR) : qui est un routeur d’extrémité qui joue un rôle important
dans l’assignation et la suppression des labels au moment où les paquets entrent dans le réseau ou en
sortent.
Les différents labels qui seront assignés à chacun des paquets définiront un chemin appelé
Label Switch Path (LSP). Celui-ci peut être statique ou dynamique, selon qu’il est défini ou qu’il utilise
les informations de routage. Il est fonctionnellement équivalent à un circuit virtuel ATM ou Frame Relay.
L’architecture de la technologie MPLS est constituée d’un plan de contrôle et d’un plan de
données (Control Plane et Data Plane)
Echange
d’informations
sur le routage
Echange de
Labels
Paquets IP Paquets IP
reçus expédiés
Paquets labellisés
Reçus Paquets labellisés
Expédiés
Figure 12: Structure des LSR et du Edge LSR
Page 21
Dans MPLS, les flux de données du plan de contrôle et du plan de données sont logiquement
séparés.
Le plan de contrôle est composé de l’ensemble des protocoles de distribution des labels et des protocoles
de routage. Il est responsable de la construction, de la maintenance des tables d’acheminement
(Forwarding Tables), à savoir la table de routage (IP routing table) qui crée à son tour l’IP forwading
table (FIB :Forwading Information Base) se trouvant dans le DATA Plane. Il est aussi responsable de la
communication inter-noeuds (LSR) afin de disséminer les informations concernant le routage.
Les protocoles de distribution des labels utilisés sont CR-LDP ou RSVP-TE. Ils sont
responsables de l’échange de labels et de la construction de d’autre forwading table : Label Information
Base (LIB) dans le plan contrôle et Label Forwading Table (LFIB : label forwading information base)
dans le DATA plan.
Le plan de data est responsable de transporter les paquets commutés à travers le réseau en se
basant sur les " Forwarding Tables " décrites précédemment. Il correspond à l’acheminement des données
en accolant un " Shim header " aux paquets arrivant dans le domaine MPLS. Comme c’est illustré sur les
deux figures, la seule différence qu’il y a entre un LSR et un Edge LSR est la non existence de la FIB
dans le LSR : ce qui est évident puisque le LSR ne reçoit que des paquets labellisés et n’envoie que des
paquets labellisées.
3.3- Le protocole LDP : label distribution protocole :
Un protocole de distribution des labels est un ensemble de procédures par lesquelles un LSR
en informe un autre des affectations label/FEC qu’il a faites.
Il peut être souhaitable de rajouter d’autres fonctionnalités à un protocole de distribution des
labels, comme par exemple le fait de pouvoir aussi sélectionner et réserver des ressources dans le réseau
le long d’un LSP. Pour cela il y a deux manières de procéder :
• Utiliser un protocole servant déjà à la réservation de ressources et l’étendre afin qu’il puisse aussi
faire de la distribution de labels.
• Utiliser un protocole servant à l’origine à la distribution de labels et l’étendre afin qu’il puisse
aussi faire de la réservation de ressources.
3.4- Tables MPLS: LIB et LFIB :
A partir des informations apprises par LDP, les LSR construisent deux
Tables, la LIB et la LFIB. De manière générale, la LIB contient tous les labels appris des LSR voisins,
tandis que la LFIB, utilisée pour la commutation proprement dite des paquets, c’est à dire désignant le
meilleur prochain hop pour atteindre le réseau de destination, est un sous-ensemble de la LIB.
Page 22
Figure 13 : Constructions des tables LIB et LFIB
3.4.1- Rôle de la LIB : label information base :
La première table construite par le routeur MPLS est la table LIB (Label Information Base).
Elle contient pour chaque subnet IP la liste des labels affectés par les LSR voisins. Ainsi, elle donne au
routeur une vue globale sur le backbone MPLS.
3.4.2- Rôle de la LFIB : label forwarding information base :
A partir de la table LIB et de la table de routage IP, le routeur construit une table LFIB, qui
sera utilisée pour commuter les paquets. Chaque réseau IP est appris par l'IGP, qui détermine le prochain
saut ("next-hop") pour atteindre ce réseau. Le LSR choisit ainsi l'entrée de la table LIB qui correspond au
réseau IP et sélectionne comme label de sortie le label annoncé par le voisin déterminé par l'IGP (plus
court chemin).
Le routeur, lorsqu'il reçoit un paquet taggué, se base sur la TFIB pour forwarder le paquet. A partir d'un
label d'entrée (local tag), il en déduit l'interface et le label de sortie (Outgoing interface et Outgoing tag).
Pour pouvoir utiliser la LFIB, le routeur doit employer CEF comme technique de commutation, qui doit
être activée globalement et pour chaque interface recevant des paquets taggués.
CEF est en effet le seul mode de commutation capable d'utiliser la TFIB.
4- Les modes de MPLS :
4.1- Notion de Downstream :

Le schéma suivant explicite la notion d' « upstream neighbour » et de « downstream neighbour »
par rapport à un réseau IP donné:
Page 23
Figure 14: Upstream et Downstream neighbour en IP
Sur le schéma ci-dessus, le routeur A est un upstream neighbour par rapport au routeur B pour le
réseau 192.168.2.0. Le routeur A est aussi downstream neighbour par rapport au routeur B pour le réseau
192.168.1.0. Autrement dit, pour une transmission vers le réseau 192.168.2.0, le routeur A est
l’antécédent (upstream) du routeur B et le routeur C son prédécesseur (downstream).
4.2- Allocation et distribution des labels en Frame mode MPLS : «

unsollicited downstream »
4.2.1- Les étapes Allocation et distribution des labels en Frame mode MPLS :
L’allocation et la distribution des labels dans un backbone MPLS en frame mode sont
réalisées par les étapes suivantes :
1. Les protocoles de routage IP construisent la table de routage IP
Figure 15: construstion des IP routing tables et Allocation des Labels (Etape 1)
Les protocoles de routages sont utilisés pour construire les IP routing table pour tous les
LSR. La FIB n’est construit que pour le Edge LSR A en se basant sur son IP routing table, mais sans
aucune information se rapportant aux labels.
2. Chaque LSR assigne indépendamment un label pour chaque réseau de destination dans la table de
routage
Page 24
Figure 16 : Allocation des Labels (Etape 2)
3. Chaque LSR informe tous les autres LSR des affectations qu’il a fait pour chaque destination
Figure17: Distribution des Labels (Etape 3)
Chaque LSR stocke l’information reçue du LSR B dans sa LIB, ainsi que l’Edge LSR A qui
la stocke dans sa FIB. Ainsi, au lieu que le routeur A envoie le paquet IP qu’il reçoit comme un simple
paquet IP, il l’envoie labellisé par l’étiquette 25 et mettant en fonction le backbone MPLS.
4. En se basant sur ces informations envoyées, chaque LSR construit ses propres tables : LIB, LFIB,
FIB.
Page 25
Figure 18 : Remplissage de la LIB
Figure 19 : Remplissage de la LFIB
Ainsi, les LSR downstream propagent systématiquement tous leurs labels à leurs voisins.
Cette variante de distribution est nommée : unsollicited downstream.
4.2.2- Penultimate Hop Popping :
Un LSR "Egress" annonçant un réseau, qui lui est soit directement connecté, soit rattaché
par une interface non tagguée, n'a pas besoin de recevoir de paquets taggués pour atteindre ce réseau. En
effet, si les paquets reçus étaient taggués, le routeur Egress devrait d'abord déterminer l'interface de sortie
grâce à la table LFIB, puis effectuer une recherche dans la FIB. L'opération de recherche sur le label dans
la LFIB est inutile, car dans tous les cas le routeur devra effectuer une recherche dans la table de routage.
Le routeur Egress annonce donc ces réseaux IP avec le label "implicit-null" à ses voisins. Un
LSR ayant comme label de sortie "implicit-null" aura ainsi pour but de dépiler le premier label du paquet
et de faire suivre le paquet sur l'interface de sortie spécifiée. Le routeur Egress n'aura alors plus qu'une
recherche à faire dans sa table de routage.
Page 26
Figure 20: Expédition sans Penultimate Hop Poppping
Figure 21 : Penultimate Hop Popping
4.3- Allocation et distribution des labels en Cell mode MPLS:«

downstream on demand »
Il existe deux manières d'implémenter MPLS sur des réseaux de type ATM.
La première consiste à mettre en place un backbone constitué de switches purement ATM, c'est-à-dire
sans aucune connaissance de MPLS ou du routage IP.
Dans ce cas, des PVCs sont simplement établis entre les routeurs MPLS et les labels sont
alors encapsulés entre l'entête LLC/SNAP et l'entête IP. La deuxième méthode consiste à mettre en œuvre
MPLS sur des switches ATM dits « IP-aware », c'est-à dire ayant connaissance de la topologie IP grâce à
un protocole de routage, et où l'information de label est encodée dans les champs VPI/VCI. Ces switches
Page 27
sont alors appelés ATM LSR. Ce paragraphe aborde les spécificités d'un backbone MPLS composé de
LSR ATM par rapport à un backbone purement IP, notamment dans les mécanismes de distribution des
labels. Le MPLS sur ATM natif ayant un fonctionnement similaire à des LSR « traditionnels », cette
architecture ne sera pas étudiée ici. Pour distribuer des labels MPLS entre LSR ATM, les protocoles
TDP/LDP en mode downstream on demand sont utilisés. Si le mode unsollicited downstream était
employé, comme dans le cas de LSR non ATM, on aurait le scénario suivant :
Figure 22: Scénario du « unsollicited downstream »
Dans cet exemple, le routeur C aurait fourni au switch ATM le label 4 pour atteindre le
subnet 192.168.1.0/24. On remarque alors que si des paquets IP sont envoyés par les routeurs A et B à
destination de ce subnet, les cellules ATM reçues par le routeur C ont toutes pour label « 4 ». Le label
étant encodé dans les champs VPI / VCI pour des LSR ATM, il y a mélange des cellules composant les
paquets IP, sans moyen de resynchronisation (impossible de distinguer les cellules les unes des autres
pour reformer les paquets). La solution mise en œuvre pour éviter le mélange des cellules est d'affecter un
label en fonction du subnet de destination et de l'interface d'entrée. Dans ce cas de figure, les LSR
upstream demandent à leurs voisins downstream de leur fournir un label pour chaque subnet IP et pour
chacune de leur interface d'entrée. Ce mode de fonctionnement est donc appelé «downstream on
demand ». Il est à noter que le choix du mode de distribution des labels est fixé automatiquement de
manière optimale par les routeurs (en fonction du type des interfaces), sans possibilité de modification au
niveau de la configuration.
Le schéma ci-dessous montre le fonctionnement des LSR ATM avec un label de sortie défini
pour chaque couple (interface d'entrée, subnet IP) :
Page 28
Figure 23 : Scénario du « downstream on demand »
Sur cet exemple, le switch ATM, fonctionnant en mode downstream on demand, a demandé
au routeur C de lui fournir deux labels (2 et 6) pour atteindre le subnet 192.168.1.0 : un label différent est
alors utilisé en fonction de l'interface d'entrée pour atteindre le même subnet. L'allocation de plusieurs
labels, mappés dans les champs VPI/VCI, peut rapidement dépasser les limites des équipements ATM. En
effet, bien que les champs VPI/VCI soient codés sur 32 bits, il peut exister des limitations hardware, qui
dans certains cas, ne permettent pas d'utiliser plus d'un certain nombre de VC par interface. Le VC Merge
permet de réduire le nombre de labels utilisés sur une interface ATM, tout en gardant les paquets IP
synchronisés. Le principe de cette méthode est de grouper les cellules composant un paquet IP dans un
buffer et de ne les émettre sur l'interface de sortie que lorsque tout le paquet a été reçu. Les cellules sont
émises dans l'ordre et le LSR downstream les recevant peut donc reconstituer le paquet sans risque de
mélange, grâce au champ End Of Frame de l'entête AAL5.
Page 29
Chapitre III :
Implémentation d’un réseau MPLS sous
GNS 3
Page 30
1. Introduction:
Dans ce chapitre, On va commencer par décrire l’outil de simulation utilisé pour la

l’implémentation de la technologie MPLS: dynamips/ Dynagen/GNS3. On se focalisera après sur la
présentation et l’implémentation de différents protocoles pour la création du MPLS.
2. Outil de simulation:
Dynamips / Dynagen / GNS3 sont des logiciels libres qui permettent l'émulation des
machines virtuelles Cisco. Au contraire des simulateurs commerciaux (Boson, Network Vizualiser, etc.)
ou gratuits (Packet Tracer) qui reproduisent le comportement des IOS et des machines, Dynamips /
Dynagen / GNS3 utilisent un véritable IOS entièrement fonctionnel. Ils émulent seulement le Hardware.
Bien que les performances d'un environnement de production ne puissent pas être atteintes, il s'agit d'une
alternative crédible à l'acquisition d'un laboratoire de test coûteux.
GNS3 est un simulateur graphique de réseaux qui vous permet de créer des topologies de
réseaux complexes et d'en établir des simulations. Ce logiciel, est un excellent outil pour l'administration
des réseaux CISCO, les laboratoires réseaux ou les personnes désireuses de s'entraîner avant de passer les
certifications CCNA, CCNP, CCIP ou CCIE.
CCIE. De plus, il est possible de s'en servir pour tester les
fonctionnalités des IOS Cisco ou de tester les configurations devant être déployées dans le futur
f sur des
routeurs réels.
2.1 Présentation :
Dynamips: estst le logiciel qui émule une machine virtuelle des plateformes C7200 ou
C3600. Il est supporté sous Linux ou sous Windows XP. Pour faire fonctionner une machine virtuelle, il
faut un IOS valide que l'on peut obtenir par un compte Cisco, ou bien par le logiciel Isohunter.
Page 31
Dynagen: est une interface supplémentaire écrite en Python qui facilite la gestion et
l'interconnexion de plusieurs machines virtuelles. Bien qu'il soit possible de recréer un environnement
complet de laboratoire avec Dynamips, Dynagen autorise la modification aisée d'une topologie.
En aucun cas, Dynamips / Dynagen ne remplacent de vraies machines car les interfaces sont émulées et
leur débit est très faible. Par contre, ILS sont des logiciels particulièrement intéressants pour:
• L'entraînement, la pédagogie et la familiarisation avec les produits et les technologies Cisco
System,
• L'élaboration de prototypes en vue de tester des fonctionnalités IOS,
• La vérification rapide de configuration à déployer plus tard dans un environnement de production.
GNS3: est une interface graphique (GUI) écrite en Python qui utilise les deux logiciels
Dynamips/Dynagen. Un binaire d'installation avec toutes les dépendances est fourni à partir de cette page.
Il suffit de configurer l'emplacement de l'image IOS et d'optimiser la valeur Idle-PC.
Figure 24: Association d’une image IOS à GNS3
2.2 Fonctionnalités Dynamips :

Les plateformes actuellement émulées sont :
• C7200
• C3600
• C3700
• C2600
• C1700
La console est disponible en connexion Telnet. On peut également :
Page 32
Lancer un mode 'Hypervisor' pour démarrer et contrôler plusieurs instances en même temps,
Connecter directement les interfaces des machines,
Connecter un PA ou un NM à une interface de la machine hôte,
Connecter la console virtuelle de la machine virtuelle à un vrai port sériel de la machine hôte,
Emuler des ponts virtuels,
Emuler des commutateurs Ethernet virtuels (supportant le trunking 802.1q),
Emuler des commutateurs ATM virtuels,
Emuler des commutateurs Frame-Relay virtuels.
Une fois que vous avez chargé tous les IOS images que vous avez besoin, vous êtes prés a
commencé votre topologie et le pouvoir sur votre routeur :
Figure 25: Console de configuration d’un routeur
Comme vous pouvez le voir, l’IOS est totalement ignorant sur la couche de virtualisation et
tous fonctionne comme sur du matériel réel.
2.3 Fonctionnalités du Dynagen :
Dynagen est l'interface supplémentaire (basée texte) qui va faciliter la maintenance des
fonctionnalités de Dynamips en utilisant le mode 'Hypervisor' décrit plus haut. Son principal avantage est
la gestion aisée de plusieurs réseaux virtualisés:
L'usage de fichiers de configuration simples et compréhensibles pour configurer et interconnecter

les machines virtuelles,
L'usage d'une architecture client/serveur qui autorise une multitude de machines virtuelles sur une
ou plusieurs machines hôtes,
Une interface de gestion en CLI pour lister, démarrer, arrêter, suspendre, reprendre, redémarrer et
se connecter aux consoles des différents routeurs virtuels,
Page 33
Ecrit en Python, les librairies sont modulaires et réutilisables,
On peut également capturer le trafic sur les interfaces des routeurs (protocoles de routage,
protocoles WAN,...) en fichiers CAP lisibles par WireShark par exemple.
2.4 Installation du Dynagen sous WINDOWS XP :

Etape 1: Télécharger et installer Winpcap,
Etape 2: Télécharger et installer de Dynagen (Dynamips compris),
Etape 3: rechercher une image de C7200 de préférence pour commencer, ou une autre si vous êtes
familier avec la syntaxe des fichiers de configuration,
Etape 4: Placer la dans le dossier C:\Program Files\Dynamips\,
Etape 5: Décompactez l'image avec un logiciel approprié, par exemple 7-zip et renommez la
router.bin par exemple,
Etape 6: Editez un des fichiers qui se situent dans un des dossiers C:\Program Files
\Dynamips\sample_labs. En remplaçant la directive image par C:\Program Files\Dynamips\router.bin.
2.5 Configuration du Idle-PC dans GNS3 sous WINDOWS :
Si on ne définisse pas une valeur Idle-PC, le processeur atteindra une charge de 100% en
permanence. En fait, Dynamips ne distingue pas les moments d’inactivité des moments utiles des
machines virtuelles. La valeur Idle-PC sert à "endormir" la machine virtuelle de temps en temps quand
cette boucle est exécutée. La consommation en processeur sera alors réduite sans pour autant diminuer les
performances des machines virtuelles concernées. En mode Emulation, on allume le routeur, on lance la
console CLI du routeur et dans la console de gestion Dynagen, on tape la commande « idlepc get » suivi
du nom. L’étude de cas consiste dans une implémentation du réseau MPLS, en utilisant l’émulateur
GNS3 et des routeurs C7200.
3. Mise en place du protocole LDP au backbone :
Pour la mise en place de l’environnement de routage de l’opérateur, on va commencer par la

configuration, ensuite l’activation des adresses de toutes les interfaces de PE, P et CE. Dans cette activité,
on doit configurer le protocole de routage RIP pour toutes les interfaces du backbone MPLS. La figure 25
illustre ce qu’on doit accomplir.
Page 34
Figure 26: Interfaces et LDP pour le backbone
4. Configuration de MPLS :
Avant de commencer la configuration MPLS, il faut s’assurer que les adresses IP sont
configurées dans les différentes interfaces des routeurs. Le plan d’adressage qu’on a adopté est le
suivant :
Figure 27 : Maquette du test
Page 35
Les étapes de configuration du MPLS :
Etape 1: Activer le CEF dans les routeurs et dans leurs interfaces.
CEF (Cisco Express Forwarding) est une méthode de commutation des paquets utilisée par les IOS
de Cisco. C’est la dernière méthode développée par Cisco, et elle est primordiale avant la configuration
MPLS.
Router (config)# int fa 0/0
Router (config-if)# ip route-cache cef
Cette configuration doit être faite dans tous les routeurs du Backbone MPLS (PE1, PE2, P1 et P3).
Etape 2: configurer un protocole de routage IGP.
A l’intérieur du domaine IP MPLS il faut utiliser un protocole de routage IGP ; OSPF, ISIS ou RIP.
On a choisi le protocole RIPv2.
Entre les PEs et CEs, on peut utiliser les protocoles RIPv2, OSPF, Static, EIGRP ou MP-BGP.
Les commandes pour configurer RIPv2 sont les suivantes :
Router (config) # router rip
Router (config) # version2
Router (config) # network @ip
Si le protocole de distribution de label configuré dans les routeurs est autre que LDP, et on veut
configurer LDP (le protocole configuré par défaut est LDP) on peut utiliser la commande suivante :
Router (config)# mpls label protocol ldp
Etape 3: Assigner le LDP router ID.
LDP utilise la plus grande adresse IP dans les interfaces loopback (une interface loopback est une
interface virtuelle qui permet à un routeur de communiquer avec lui-même) comme LDP router ID. Si
aucune interface loopback n’est définie, la plus grande adresse IP dans le routeur devient le LDP router
ID. L’adresse loopback est recommandée car elle reste toujours up.
Pour forcer une interface à devenir le LDP router ID on utilise la commande suivante :
Router (config)#mpls ldp router-id interface-type number
Exemple: router (config)#mpls ldp router-id loopback 0
Etape 4: Activer IPv4 MPLS ou label forwarding dans les interfaces.
Page 36
Pour toutes les interfaces on fait comme suit :
Router (config) # interface interface-type number
Router (config-if) # mpls ip
Après avoir configuré les routeurs au sein du nuage MPLS ainsi que les deux routeurs externes au
nuage, nous avons fait une capture du trafic entre edge LSR1 et LSR1 (dans le nuage MPLS), et ceci à
l’aide du logiciel wireshark (anciennement Ethereal) qui est un logiciel libre d'analyse de protocole, ou
« packet sniffer », utilisé dans le dépannage et l'analyse de réseaux informatiques, le développement
de protocoles et l'éducation, mais aussi le piratage, nous avons pu effectuer plusieurs capture de trafic,
dans la première capture nous ne pouvons relever que le protocole RIP responsable des convergences des
tables de routage tandis que dans la deuxième capture on peut effectivement relever LDP protocole de
liaison des labels.
Figure 28: Capture du trafic hors du backbone MPLS
Page 37
Figure 29 : Capture du trafic dans le backbone MPLS
Page 38
CHAPITRE IV :
Gestion de la qualité de service d’un
réseau IMS via un backbone MPLS
Page 39
1. Introduction :
Les paquets Internet arrivent en désordre, en retard et parfois avec perte. Ce n'est plus le cas avec
l'IMS, vu la QoS assurée de bout en bout. Il est possible que l'équipement de l'utilisateur discute sa
capacité et son besoin en qualité de service durant l'établissement d'une session SIP (Sission Initiation
Protocol). Les paramètres susceptibles d'être discutés sont:
− Type de média, direction du trafic.
− Débit binaire, taille du paquet et leur fréquence du transport.
− L'usage de la charge RTP pour les types de média.
− Adaptation de la bande passante.
Apres avoir discuté les dits paramètres au niveau applicatif, l'équipement de l’utilisateur procède à
une réservation des ressources qu'il lui faut à partir du réseau d'accès. Maintenant que la QoS de bout en
bout est créée, le terminal encapsule ses paquets à l'aide d'un protocole approprié (RTP), ensuite
transférés, via l’IP, vers le réseau d'accès et de transport avec l'un des protocoles de la couche transport.
Alors Dans ce chapitre, nous allons étudié la qualité des services fournis par IMS. Notre objectif est
d’essayer d’améliorer cette qualité grâce à la gestion de QOS fournie par le protocole MPLS. Ainsi, notre
travail consiste à établir une connexion Client IMS / Serveur IMS à travers un réseau backbone doté de
MPLS afin qu’on puisse utiliser DIFFSERV pour faire la gestion de la QOS.
2. Architecture :
L’architecture suivante contient trois réseaux : Backbone MPLS, réseau IMS et réseau CLIENT.
Backbone MPLS contient trois routeurs dont deux sont des Edge LSR et un LSR.
Réseau IMS est un nuage représentant une machine qui contient le noyau IMS.
Réseau CLIENT est aussi un nuage qui représente un serveur client de IMS.
Page 40
Figure 30 : Architecture du backbone MPLS lié au serveur IMS et Client IMS
3. Configuration des routeurs :
Pour la configuration de tous les éléments de notre architecture, nous présentons à titre d’exemple la
configuration du routeur R0.
Page 41
Page 42
4. Configuration des machines: client IMS et serveur IMS

Client IMS :
Voici les démarches à suivre pour configurer le réseau CLIENT.
• Configurer le nuage sur eth0
• Pour le port eth0, on fait :
• On se déplace dans la machine client et on refait la même chose.

• Dans la console de la machine client, on tape les commandes suivantes :
Route
# route delete default gw 214.35.167.195
# route add default gw 10.10.10.1
Donc, on obtient la table suivante du routage :
Serveur IMS :
La configuration d’un serveur IMS nécessite d’abord l’installation de la plate forme OPEN IMS
CORE sur une machine normale afin qu’elle puisse devenir un serveur. L’architecture d’un réseau IMS,
Comme déjà cité au dessus, se compose de plusieurs équipements dont on site principalement PROXY-
Page 43
CSCF, I-CSCF…alors l’installation de la plate forme OPEN IMS CORE devrait faire en sorte d’installer
tous les équipements du serveur. Voici un schéma détaillé de l’architecture OPEN IMS CORE :
L’installation de cette plate forme open source se fait selon plusieurs étape qui se résume à
l’installation et la configuration des équipements du serveur .Sans trop détaillé cette installation , le lien
suivant permet un guidage parfait pour implémenter IMS sur une machine dont le système d’exploitation
utilisé est UNIX ubuntu : http://www.openimscore.org/installation_guide.
Une fois IMS est installé sur le serveur, il ne nous reste plus que lancer le serveur IMS entièrement
avec les commandes :
Router /opt/OpenIMSCORE # ./ims.sh
Router /opt/OpenIMSCORE # ..pcscf.qos.rtp.sh
Router /opt/OpenIMSCORE # ./ims.qos.rtp.sh

Reste à signaler bien sur que la configuration des adresses IP de la machine IMS est identique à
celui de la machine Client IMS, cela dit on configure manuellement avant le démarrage du serveur
l’adresse réseau correspondante et la passerelle par défaut du serveur. cependant il va falloir adapter IMS
a ces nouveaux changements, Alors on accède à plusieurs fichiers de configuration de IMS, P-CSCF, I-
CSCF, S-CSCF, et sans oublier bien évidement le serveur DNS qui doit être mis à jour en modifiant les
adresses IP aux quelles il doit écouter. Voici un aperçu des modifications apportées sur les fichiers des
différentes entités :
Page 44
Ainsi, à cette étape on peut démarrer nos entités et aussi démarrer le serveur pour établir une
connexion client / serveur IMS, la figure suivante est un aperçu du lancement du serveur avec ses entités.
Page 45
La dernière étape consiste à établir la connexion entre le client et le serveur, pour cela il faudrait
avoir la plate forme UCTIMSCLIENT qui permet à n’importe quelle machine client de s’enregistrer
auprès su serveur afin de bénéficier des services IMS, la figure suivante est l’aperçu de la plate
forme lancé grâce au terminale SHELL du client comme suit :
Page 46
Grâce à cette plateforme, le client peut alors communiquer avec le serveur et bénéficier des
différents services offerts par celui-ci,
ci, cette communication se fait suivant cinq étapes :
- l’enregistrement du client chez le serveur : comme la montre la figure ci-dessus,
ci il envoie
une requête d’enregistrement au serveur.
- Authentification du client : le serveur IMS authentifie le client et l’enregistre
l’enregist dans sa base de
données HSS. Puis il envoie une réponse au client pour lui dire qu’il
qu’il est enregistré sur le serveur.
serveur
- Démarrage du serveur des applications comme iptv pour établir les liens sur les canaux de
connexions entre les deux bouts. Sur cette plateforme
pla il y a au total trois canaux.
- Demande d’invitation de la part du client : en effet le client envoie une requête de demande
deman
de service vidéo par exemple.
- Fourniture des services : le serveur envoie le service demandé par un client enregistré après
avoir
voir reçu l’invitation de sa part. Voici un aperçu de connexion avec trois services fournis par le serveur
au client : Vidéo en UDP (avec VLC player),
player), vidéo en RTP et Messagerie instantanée :
Page 47
Finalement, les deux machines étant configurées, et l’architecture MPLS également, il faut
maintenant utiliser des paquets d’envoie simples comme le ping par exemple afin de vérifier le passage
des flux.
5. Test de l’architecture MPLS-IMS

MPLS avec des pings :
L’architecture MPLS établie auparavant permet de faire relier deux machines l’une client IMS et
l’autre serveur IMS. Cette connexion doit être au premier lieu testée par des simples requêtes ICMP de
ping.
On lance alors la commande à partir des deux bouts de la connexion : le client et le serveur :
Débian : # ping 10.10.2.2 // lancement du ping vers le serveur IMS

Le résultat de ce ping peut être visualisé grâce a WIRESHARK en capturant les trames sur l’un des
liens sur le réseau : voicii un aperçu de cette capture montrant les paquets ICMP requête et réponse entre
le client 10.10.10.2 et le serveur 10.10.2.2 :
Page 48
On remarque également sur cette figure l’apparition du protocole MPLS dans la trame envoyé
avec un MPLS LABEL égale à 17.
Donc le ping étant réussit de bout en bout, on en conclut ainsi que la connexion est établie et
qu’on peut effectuer des enregistrements
strements en session au serveur et échanger des services.
6. Lancement des services IMS :

Le scenario pour atteindre notre objectif de gestion de QOS consiste en fait à lancer trois services
simultanément à partir du serveur vers le client afin d’utiliser le maximum de bande passante et par la
suite pénaliser la qualité de service. En ce qui concerne les services
services à lancer, il en a plusieurs,
plusieurs mais on a
choisit trois qui demande une grande gestion de la qualité de service à savoir :
- Vidéo avec le protocole UDP UDP à travers la diffusion sur le réseau par le lecteur VLC
- Vidéo avec le protocole RTP en live streaming à travers le canal 1 du Client/serveur
- Messagerie instantanée grâce à la plate forme de chate UCTIMSCLIEN.
Comme déjà indiqué en haut,, le client doit d’abord passer par toutes les étapes de demande d’un
service auprès du serveur IMS. Alors que pour la vidéo lancée par VLC, il faut la configurer à partir du
WIZARD du VLC comme suit :
- Lancer VLC
Page 49
- accéder au FILE / WIZARD
- Choisir la vidéo à lancé et spécifier le mode de transmission broadcast /unicast/…

- On a choisit ici unicast donc on précise l’adresse ip du client 10.10.10.2.
L’étape qui suit consiste d’abord à capturer les différentes trames passant par le réseau MPLS, on
s’intéressera essentiellement au protocole RTP et UDP des différents streaming lancés. La figure
suivante montre cette capture :
Page 50
On a donc utilisé le protocole RTP et quand la trame passe dans le backbone MPLS elle est
reconnue par un MPLS LABEL ayant par numéro dans ce cas 16.
WIRESHARK permet également de faire une capture des services de streaming qui sont générer
dans une session
ion mené de plusieurs paramètres
paramètre de gestion de qualité de service dont on site
essentiellement :
• DELTA (ms) : le temps du retard des trames.

trames
• BW (kbps) : la bande passante allouée au service.
• Lost : taux de pertes des paquets.
• …….etc.
En somme il y a plusieurs paramètres

paramètre et on choisit de visualisé les DELTA times
afin de voir la différence des temps entre l’utilisation du BEST EFFORT et de
DIFFSERV
Page 51
7. Test de la qualité de service IMS gérée avec BEST EFFORT :
Ainsi,, les services étant lancés, on peut maintenant faire une étude sur la qualité de service du
serveur IMS. Dans le réseau MPLS,, on n’a pas encore utilisé un protocole de gestion de la QOS comme
Diffserv ou intserv mais on a laissé la gestion par défaut BEST EFFORT et voilà le résultat : une
mauvaise qualité des deux vidéos à la fois lancées et le chat n’est jamais perturbé même si il est lancé en
même temps avec du live Streaming :
Afin de mieux visualiser cette

tte mauvaise qualité de service,
service, voici un aperçu des
de streaming capturé
avec WIRESHARK et sur lequel il y’a les paramètres déjà cité :
Page 52
Onn remarque que les DELTA (ms) ont des valeurs maximales de :
- 1411 ms pour le port source 33069
- 371 ms pour le port 33085
Notre objectif consiste alors à utiliser DIFFSERV afin de diminuer le DELTAS max.
8. Configuration des routeurs avec DIFFSEFV :
Les routeurs utilisés jusqu'à présent sont configurés pour utiliser BEST EFFORT, nous allons donc
par la suite les configurer pour utiliser DIFFSERV.
Présentation
n du modèle DIFFSERV :
Au contraire du modèle IntServ qui traite indépendamment chaque flot, le modèle DiffServ
propose de séparer le trafic par classes. Le groupe Diffserv propose donc d'abandonner le traitement du
trafic sous forme de flots pour le caractériser sous forme de classes. Chaque classe est identifiée par une
valeur codée dans l'en-tête
tête IP. Cette classification doit se faire sur les routeurs de bordures (edge
( router) à
l'entrée du réseau.
Page 53
L'architecture des services différenciés contient 2 types d'éléments fonctionnels :
1. Les éléments de bordures (edge functions) : ils sont responsables de la classification des
paquets et du conditionnement du trafic. En bordure du réseau, c'est à dire à l'arrivée du premier
élément actif capable de traiter le champ DS (DS-capable), les paquets arrivant ont dans leur champ TOS
(pour IPv4) ou Traffic Class Octet (pour IPv6), une certaine valeur DS. La marque qu'un paquet reçoit
identifie la classe de trafic auquel il appartient. Après son marquage, le paquet est envoyé dans le réseau
ou jeté.
2. Les éléments du coeur du réseau (core functions) : ils sont responsables de
l'envoi uniquement. Quand un paquet, marqué de son champs DS, arrive sur un routeur DS-capable,
celui-ci est envoyé au prochain noeud selon ce que l'on appelle son Per Hop Behaviour (PHB) associé à
la classe du paquet. Le PHB influence la façon dont les buffers du routeur et le lien sont partagés parmi
les différentes classes de trafic. Une chose importante dans l'architecture DS est que les PHB routeurs se
basent uniquement sur le marquage de paquet, c'est à dire la classe de trafic auquel le paquet appartient ;
en aucun cas ils ne traiteront différemment des paquets de sources différentes.
L'avantage de Diffserv est qu'il n'y a plus nécessité de maintenir un état des sources et des
destinations dans les core routers, d'où une meilleure scalability.
• L'utilisateur définit pour chaque flux:
- La classe AF à utiliser (or, argent, bronze)

- Le profile du flow (paramètres token-bucket)
- A l'entrée du réseau, une étiquette est ajoutée à chaque paquet qui reflète:
- La classe AF pour le flux
- Une priorité calculée par le routeur d'entrée en fonction du respect du profile accordé.
- La différentiation entre flux est atteinte grâce à une attribution différente des priorités en
fonction du profile.
• Avantages de l'Assured Forwarding
- Peut offrir une meilleure différentiation

- Le marquage à l'entrée du réseau est une opération moins coûteuse que le shaping.
- Il ne demande pas une coordination entre domaines.
- Une facturation simple peut être utilisée.
Page 54
• Inconvénients de l'Assured Forwarding
- La qualité offerte dépend énormément du niveau d'agrégation et de la présence de flux

concurrents.
- Il n'existe aucune assurance de délai.
Création d'une politique de qualité de service :
a. Filtrage des flux :

Pour établir une qualité de service il faut tout d'abord sélectionner les flux qu'on veut différencier.
Pour cela on utilise une certaine technique de filtrage disponible dans l'IOS du routeur qui est l'utilisation
d'ACLs (Access Control List).
Une liste de contrôle d'accès est une collection d'instructions permettant d'autoriser ou de refuser
des paquets en fonction d'un certain nombre de critères, tels que:
- L'adresse d'origine
- L'adresse de destination
- Le numéro de port.
- Les protocoles de couches supérieures
Il existe 3 types de liste de contrôle d'accès:
Les ACLs standards,

Les ACLs étendues et
Les ACLs nommées.
• Les ACLs standards utilisent des spécifications d'adresses simplifiées et autorisent ou

refusent un ensemble de protocole.
C'est-à-dire en d'autres termes que l'on peut interdire par exemple à une machine l'accès à une autre
machine ou à un autre réseau.
• Les ACLs étendues utilisent des spécifications d'adresses plus complexes et autorisent ou
refusent des protocoles précis.
Ce type d'ACL utilisent un filtrage bien plus spécifique - on peut selon nos besoins, interdire (ou
permettre) des flux depuis et vers une autre machine (ou réseaux) suivant des critères tels :
- Le type de protocole de niveau 4 (en l'occurrence TCP ou UDP).

- Le numéro de port utilisé.
- Ou même le type de l'application (ftp,telnet .....).
- Les ACLs nommées peuvent être soit standards, soit étendues; elles n'ont pour but que de
faciliter la compréhension et de connaître la finalité de l'ACL.
-
Au moment de configurer les listes de contrôle d'accès il faut identifier chaque liste de protocole en
lui attribuant un numéro unique.
Le numéro choisi pour identifier une liste de contrôle d'accès doit se trouver à l'intérieur d'une plage
précise, valable pour le protocole.
Page 55
Plage Protocole
1-99 IP Standard
100-199 IP Etendue
600-699 AppleTalk
800-899 IPX Standard
900-999 IPX Etendue
1000-1099 IPX Service Advertising Protocol
Par exemple, si l'on affecte le numéro 30 à une ACL, cela induit le fait que cette ACL sera de type
standard et concernera le trafic IP.
Tandis que le numéro 950 indiquera que cette ACL est de type étendue et pour le trafic IPX.
Paramètres d'une ACL :
access-list numéro { permit ou deny } protocole source destination opérateur

(numéro de port)
Numéro : voir tableau ci-dessus

Protocole : IP, TCP, UDP, ICMP, GRE, IGRP
Source : adresse source
Destination : adresse destination
Opérateur : lt less than (plus petit que), gt greater than (plus grand que), eq equal (egal à),
neq not equal (différent de)
Numéro de port : le numéro de port de l'application.
Dans notre cas le filtrage ce fait au niveau de l'application et par conséquent au niveau du numéro
de port c'est pourquoi nous avons utilisé des ACLs de type étendues.
Lors d'une communication établie avec NetMeeting, nous avons utilisé la

commande netstat dans une fenêtre ''cmd'', afin de connaître le port utilisé. Comme c'est un numéro
fixé aléatoirement à chaque communication, nous avons recommencé ceci plusieurs fois afin d'avoir une
gamme moyenne : numéro de port : de 1050 à 2000.
Routeur# access-list 101 permit tcp any any range 1050 2000
Page 56
access-list : commande pour la création d'un filtre.

101: numéro choisit correspondant à une ACL de type étendu (voir Tab.1)
permit: on permet le passage de ce type de trafic
tcp: pour indiquer que le protocole de niveau 4 est TCP.
any: adresse source (équivalent à tout le monde).
any: adresse destination (équivalent à tout le monde).
range: on donne la plage des numéros de ports.
Maintenant pour capturer le flux FTP on utilise les commandes:
Routeur# access-list 102 permit tcp any any eq ftp
Routeur# access-list 102 permit tcp any any eq ftp-data
La première ligne correspond à la capture à un filtrage des paquets correspondant au contrôle de

transfert de données FTP (port 20)
La deuxième correspond aux flux de données FTP (port 21).
b. Classification du trafic :
Après avoir établir le filtrage il faut classifier les différents flux et les mettre dans des groupes
différents. Pour cela on utilise le système de classe disponible dans l'IOS du routeur.
Une classe de trafic contient trois éléments essentiels:
- Le nom de la classe,
- Une série de commandes match,
- Et comment évaluer ces commandes match.
Les commandes match sont utilisées pour spécifier divers critères de classification des paquets.
Les paquets sont vérifiés pour déterminer s'ils appartiennent ou non à ces critères spécifier par la
commande match.
Si un paquet appartient à un de ces critères il sera alors considéré comme membre de cette classe et
sera transféré suivant les spécifications de qualité de service indiqué dans une policy-map (sera
expliqué par la suite).
En utilisant la classification des paquets on peut par la suite partitionner notre réseau en plusieurs
niveaux de priorités ou en classes de services (class-map).
Paramètres des class-map
routeur(config)#class-map nom-de-la-classe
Page 57
On associe un nom à une class-map pour mieux la désignée par la suite
routeur(config)#class-map match-all nom-de-la-classe
On spécifie que TOUS les critères doivent être vérifier pour que le paquet appartienne à la classe.
routeur(config)#class-map match-any nom-de-la-classe
On spécifie qu'AU MOINS un des critères doivent être vérifier pour que le paquet appartienne à la
classe.
routeur(config-cmap)#match access-group numéro-de-l'ACL
On spécifie que le paquet doit vérifier l'ACL correspondante pour qu'il appartienne à la classe.
routeur(config-cmap)#match any
On spécifie que tous les paquets seront dans cette classe.
routeur(config-cmap)#match {destination ou source}-address

mac adresse
On spécifie que le paquet doit vérifier l'adresse MAC source ou destination pour qu'il appartienne à
cette classe.
routeur(config-cmap)#match input-interface nom-de-l'interface
On spécifie que le paquet doit vérifier l'interface d'entrée indiquer pour qu'il appartienne à la classe.
routeur(config-cmap)#match ip dscp valeur-du-ip-dscp
Pour l'utilisation de DiffServ on a la possibilité de spécifier la valeur du ip dscp entre 0 et 63

pour que le paquet appartienne à la classe.
routeur(config-cmap)#match ip precedence valeur-de-champs-TOS
3 bits du champ TOS dans l'entête ip forment l'IP precedence utilisé pour la qualité de service. Dans
un paquet reçu, si la valeur de ce champ est égale à la valeur indiquée ici alors le paquet appartient à cette
classe.
routeur(config-cmap)#match protocol protocole
Page 58
On spécifie le protocole suivant lequel les paquets appartiennent à la classe

Dans notre cas on a utilisé les access-list déjà créé pour effectuer la répartition des différents
flux dans différentes classes :
Exemple :
Routeur(conf)# class-map ftp
Routeur(conf-cmap)# match access-group 102
Routeur(conf-cmap)# exit
Routeur(conf)# class-map video
Routeur(conf-cmap)# match access-group 101
Routeur(conf-cmap)# exit
c. Création d'une politique de service :
Maintenant qu'on a différencié le trafic on doit partager la bande passante de notre routeur.
C'est pourquoi on doit utiliser des cartes de priorités (policy-map)
C'est à partir du moment où on utilise les policy-map, qu'effectivement on met en place la
Qualité de Service voulue.
Une policy-map contient trois éléments :
- Le nom de la police,
- Les classes associer et
- Les commandes de qualité de service
Paramètres des Policy-map
routeur(config)#policy-map nom-de-la-policy-map
On spécifie un nom pour la policy-map
routeur(config-pmap)#class nom-de-la-classe
On spécifie le nom de la classe sur laquelle on veut appliquer la politique de qualité de service
routeur(config-pmap-cmap)#bandwidth debit en kbps ou pourcentage
On spécifie la bande passante du routeur qu'on veut allouer à cette classe
routeur(config-pmap-cmap)#pritority en kbps ou en percentage
Page 59
On spécifie pour la classe une bande passante avec un niveau de priorité élevé
Cette commande est en général utilisée pour le trafic temps réel.
Configuration des routeurs CISCO avec DIFFESERV :
Après avoir découvert le modèle DIFFSERV, nous allons maintenant passer à sa pratique en
l’appliquant sur notre réseau MPLS backbone. Le scenario consiste à l’envoie de trois services via le
réseau et de faire leur gestion par DIFFSERV. La configuration à implémenter est la suivante :
On a d’abord trois services (VLC, IPTV et MI), donc il nous faut créer trois classes MAP sur les
routeurs LER1 et LER2 des frontières (EDGE) du réseau MPLS :
Création des access-list control :
On a choisit de filtrer les trafics reçus par numéro de port propre à chaque protocole de la couche
application utilisé dans iptv (RTP), dans VLC ( port 1234) et dans la messagerie ( protocole SIP )
access-list 101 permit udp any any range 16384 34000(traffic video IPTV avec
RTP)
access-list 102 permit udp any any range 1000 2000(traffic de la video VLC)
access-list 103 permit udp any any range 5000 6000(traffic de la mssagerie
instantanée )
Création des classes :
On a besoin dans notre cas de créer trois classes de trafic différentes.
class-map match-all vlc
match access-group 102
class-map match-all iptv
class-map match-all Message
Page 60
positionnement de la valeur du DSCP :
policy-map SETDSCP
class vlc
set ip dscp 46
class iptv
set ip dscp 40
class message
set ip dscp 26
Ainsi, on a crée une politique de marquage par les routeurs d’entrée du réseau , cette politique
permet de donner à chaque type de trafic un numéro de DSCP pour le traiter grâce à celui-ci.le traitement
choisit pour la priorité est celui de la bande passante utilisé , on va alloué plus de bande passante au
service IMS par rapport au service VLC dans notre cas.
Allocation de la bande :
policy-map QoSVIDEO
class rtp
bandwidth percent 50
class message
class vlc
Ainsi, nous sommes parvenu a faire une gestion de trafic uniquement en allouant plus de bande
passante au service IMS.
Page 61
9. Test de l’Amélioration de la qualité de service avec DIFFSERV :
L’utilisation de DIFFSERV sur le protocole MPLS a permis une meilleure gestion de service en
différenciant chaque trafic et le traiter à part,
part le résultat de ce traitement est illustré par
p la capture suivant
qui montre que la qualité de la vidéo IPTV avec RTP est meilleure que celle de VLC :
Il reste à vérifier que le paramètre qu’on surveillait avant pour la qualité des services a changé vers
le mieux, c’est le paramètre DELTA : le temps de retard des paquets UDP RTP avec IPTV .Alors avec
BEST EFFORT on avait DELTA égale a 397 ms alors qu’après traitement nt avec DIFFSERV le DELTA
est devenu égale a 44 ms. La capture suivante montre le nouveau DELTA.
DELTA
Page 62
Page 63
CONCLUSION
MPLS avait été crée pour améliorer les performances des réseaux haut débits, notamment en
terme de routage. Grâce à ces mécanismes de commutation de labels avancés, sa simplicité de mise en
place sur des réseaux déjà existants et d’y implémenter des technologies comme le QOS, VPN, VOIP. Le
MPLS est devenu une technologie de demain alliant souplesse et performance pour un coût réduit.
Nous avons commencé, dans le chapitre I, par une étude théorique sur l’architecture IMS.
Dans le Chapitre II, les concepts de base de MPLS. Dans le chapitre II, nous nous avons étudié le principe
de fonctionnement de la technologie MPLS.
Ceci nous a préparé à la deuxième phase de ce projet qui est la simulation du

fonctionnement de MPLS. Nous avons pour cela présenté dans le chapitre III, l'environnement de
simulation GNS3, et nous nous sommes concentrés dans cette partie à la manière de la configuration du
MPLS. Ainsi, nous avons réussi à implémenter un réseau MPLS.
Enfin ,dans la troisième partie , nous nous sommes focalisé sur la qualité de service sur
MPLS avec un réseau IMS. Cela dit, on a créer une connexion Client Serveur IMS à travers un backbone
MPLS afin de gérer mieux la qualité de service grâce au modèle DIFFSERV sur MPLS.
Page 64
Liste des figures
Figure1 : IMS et les NGN....................................................................................................................................8

Figure 2 : Protocoles IMS...................................................................................................................................10
Figure 3 : Architecture IMS................................................................................................................................11
Figure 4 : Routage IP..........................................................................................................................................14
Figure 5 : Gestion du réseau IP...........................................................................................................................15
Figure 6: Commutation sur ATM.......................................................................................................................15
Figure 7 : les Couches MPLS.............................................................................................................................16
Figure 8: Routeurs MPLS...................................................................................................................................17
Figure 9: Etiquette MPLS (Label)......................................................................................................................17
Figure 10: Label en Cell Mode...........................................................................................................................18
Figure 11: Label en Frame Mode.......................................................................................................................18
Figure 12: Structure des LSR et du Edge LSR...................................................................................................19
Figure 13: Constructions des tables LIB et LFIB...............................................................................................21
Figure 14: Upstream et Downstream neighbour en IP.......................................................................................22
Figure 15: construstion des IP routing tables et Allocation des Labels (Etape 1)..................................... .......22
Figure 16: Allocation des Labels (Etape 2)........................................................................................................23
Figure 17: Distribution des Labels (Etape 3)......................................................................................................23
Figure 18 : Remplissage de la LIB.....................................................................................................................24
Figure 19 : Remplissage de la LFIB...................................................................................................................24
Figure 20: Expédition sans Penultimate Hop Poppping.....................................................................................25
Figure 21 : Penultimate Hop Popping.................................................................................................................25
Figure 22: Scénario du « unsollicited downstream »…………………………………………………………..26
Figure 23 : Scénario du « downstream on demand »..........................................................................................27
Figure 24: Association d’une image IOS à GNS3..............................................................................................31
Figure 25: Console de configuration d’un routeur..............................................................................................32
Figure 26: Interfaces et LDP pour le backbone..................................................................................................34
Page 65
Figure 27 : Maquette du test...............................................................................................................................34
Figure 28: Capture du trafic hors du backbone MPLS.......................................................................................36
Figure 29 : Capture du trafic dans le backbone MPLS......................................................................................37
Figure 30 : Architecture du backbone MPLS lié au serveur IMS et Client IMS...............................................40
Page 66

Rapport Projet Dev

Transféré par

Droits d'auteur :

Formats disponibles

Rapport Projet Dev

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Projet Dev

Transféré par

Droits d'auteur :

Formats disponibles

Mini projet développement INE2

Réalisation d’un outil de gestion de QoS avec le

Réalisé par : Encadré par :

Kaoutar TEBBAA Mr M.BELLEFKIH

Cette page répond à une exigence morale bien plus

CHAPITRE II : Les concepts de base de MPLS

CHAPITRE III : Implémentation d’un réseau MPLS sous GNS 3

Liste des figures...................................................................................................................

5- Les objectifs fondamentaux de l'IMS :

• Combiner les dernières tendances technologiques

1. Supporter l'établissement des sessions multimédia IP

Les sessions multimédia IP

• des règles générales qui s'appliquent à tous les usagers

La création rapide des services

Figure 1: IMS et les NGN

6- Les protocoles de l'IMS :

Contrôle de la session : SIP

Figure 2 : Protocoles IMS

• une ou plusieurs bases de données, appelées HSS ou SLF

Figure 3 : Architecture IMS

Il faut s'assurer de la sécurité des interactions entre équipements de signalisation et de l'inviolabilité

1.1- Le Routage IP classique :

Figure 5 : Gestion du réseau IP

1.2- La Commutation ATM :

La commutation ATM fonctionne en deux phases :

Figure 6 : Commutation sur ATM

C’est donc dans ce cadre qu’est apparu le MPLS (Multi-Protocol Label

Figure 7 : les Couches MPLS

Avec MPLS, on a voulu augmenter les fonctionnalités de l’architecture conventionnelle du routage

Figure 8 : Routeurs MPLS

3- Allocation et diffusion des labels :

3.1- Format du label MPLS :

Le MPLS utilise un label de 32 bits contenant les informations suivantes :

Figure 9 : Etiquette MPLS (Label)

20 bits contiennent le label,

Figure 10 : Label en Cell Mode

Figure 11 : Label en Frame Mode

3.2- Les équipements MPLS :

Figure 12: Structure des LSR et du Edge LSR

3.3- Le protocole LDP : label distribution protocole :

3.4- Tables MPLS: LIB et LFIB :

Figure 13 : Constructions des tables LIB et LFIB

3.4.1- Rôle de la LIB : label information base :

3.4.2- Rôle de la LFIB : label forwarding information base :

4- Les modes de MPLS :

4.1- Notion de Downstream :

Figure 14: Upstream et Downstream neighbour en IP

4.2- Allocation et distribution des labels en Frame mode MPLS : «

1. Les protocoles de routage IP construisent la table de routage IP

Figure 16 : Allocation des Labels (Etape 2)

Figure17: Distribution des Labels (Etape 3)

Figure 18 : Remplissage de la LIB

Figure 19 : Remplissage de la LFIB

4.2.2- Penultimate Hop Popping :

Figure 20: Expédition sans Penultimate Hop Poppping

Figure 21 : Penultimate Hop Popping

4.3- Allocation et distribution des labels en Cell mode MPLS:«

Figure 22: Scénario du « unsollicited downstream »

Figure 23 : Scénario du « downstream on demand »

Dans ce chapitre, On va commencer par décrire l’outil de simulation utilisé pour la