Rapport Projet Dev

Mini projet développement INE2

Page 1

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é parRéalisé parRéalisé parRéalisé par :::: Encadré parEncadré parEncadré parEncadré par ::::

Kaoutar Kaoutar Kaoutar Kaoutar TEBBAA TEBBAA TEBBAA TEBBAA MMMMrrrr MMMM....BELLEFKIHBELLEFKIHBELLEFKIHBELLEFKIH

Soufiane Soufiane Soufiane Soufiane TAZARINETAZARINETAZARINETAZARINE


Page 2

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 3

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 4

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 5

CHAPITRE I : IP Multimedia Subsystem


Page 6

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 7

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 8

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 9

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 10

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 11

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 12

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 13

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 14

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 15

CHAPITRE II : Les concepts de base de MPLS


Page 16

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 17

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 18

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 19

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 20

� 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 21

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 22

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 23

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 24

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 25

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 26

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 27

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 28

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 29

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 30

Chapitre III : Implémentation d’un réseau MPLS sous

GNS 3

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 etDynagen / 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 CCIEfonctionnalités des IOS Cisco ou de tester les configurations devant être déployées dans le frouteurs réels.

2.1 Présentation

Dynamips: est le logiciel qui émule une machine virtuelle des plateformes C7200 ouC3600. Il est supporté sous Linux ou sous Windows XP. Pour faire fonctionner une machinefaut un IOS valide que l'on peut obtenir par un compte Cisco, ou bien par le logiciel


Page 31

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.

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

à 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

réseaux CISCO, les laboratoires réseaux ou les personnes désireuses de s'entraîner avant de passer les CCIP ou CCIE. De plus, il est possible de s'en servir pour tester les

Cisco ou de tester les configurations devant être déployées dans le f

Présentation :

st le logiciel qui émule une machine virtuelle des plateformes C7200 ouC3600. Il est supporté sous Linux ou sous Windows XP. Pour faire fonctionner une machine

l'on peut obtenir par un compte Cisco, ou bien par le logiciel


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.

Dynamips / Dynagen / GNS3 sont des logiciels libres qui permettent l'émulation des machines virtuelles Cisco. Au contraire des simulateurs commerciaux (Boson, Network Vizualiser, etc.)

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

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

réseaux CISCO, les laboratoires réseaux ou les personnes désireuses de s'entraîner avant de passer les . De plus, il est possible de s'en servir pour tester les

Cisco ou de tester les configurations devant être déployées dans le futur sur des

st 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

l'on peut obtenir par un compte Cisco, ou bien par le logiciel Isohunter.


Page 32

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 33

� 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 34

� 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 35

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 36

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 37

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 38

Figure 29 : Capture du trafic dans le backbone MPLS


Page 39

CHAPITRE IV : Gestion de la qualité de service d’un réseau IMS via un backbone MPLS


Page 40

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.

Figure 30 : Architecture du backbone MPLS lié au serveur IMS et

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

Architecture du backbone MPLS lié au serveur IMS et Client IMS

Configuration des routeurs :

Pour la configuration de tous les éléments de notre architecture, nous présentons à titre d’exemple la


Client IMS

Pour la configuration de tous les éléments de notre architecture, nous présentons à titre d’exemple la


Page 42


Page 43

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 44

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/OpenIMSCORERouter /opt/OpenIMSCORERouter /opt/OpenIMSCORERouter /opt/OpenIMSCORE # ./ims.sh # ./ims.sh # ./ims.sh # ./ims.sh

Router /opt/OpenIMSCORERouter /opt/OpenIMSCORERouter /opt/OpenIMSCORERouter /opt/OpenIMSCORE # ..pcscf.qos.rtp.sh # ..pcscf.qos.rtp.sh # ..pcscf.qos.rtp.sh # ..pcscf.qos.rtp.sh

Router /opt/OpenIMSCORERouter /opt/OpenIMSCORERouter /opt/OpenIMSCORERouter /opt/OpenIMSCORE # ./ims.qos.rtp.sh # ./ims.qos.rtp.sh # ./ims.qos.rtp.sh # ./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 45

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.

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 forme lancé grâce au terminale SHELL du client comme suit


Page 46

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

lancé grâce au terminale SHELL du client comme suit :


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

figure suivante est l’aperçu de la plate

Grâce à cette plateforme, le client peut alors communiquer avec le serveur et bénéficier des différents services offerts par celui-ci, cette

- l’enregistrement du client chez le serveurune requête d’enregistrement au serveur.

- Authentification du clientdonnées HSS. Puis il envoie une réponse au client pour lui dire qu’i

- Démarrage du serveur des applications comme iptv pour établir les liens sur les canaux de connexions entre les deux bouts. Sur cette pla

- Demande d’invitation de la part du clientde service vidéo par exemple.

- Fourniture des servicesavoir 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)


Page 47

Grâce à cette plateforme, le client peut alors communiquer avec le serveur et bénéficier des ci, cette communication se fait suivant cinq étapes

l’enregistrement du client chez le serveur : comme la montre la figure ciune requête d’enregistrement au serveur.

Authentification du client : le serveur IMS authentifie le client et l’enregistdonnées HSS. Puis il envoie une réponse au client pour lui dire qu’il est enregistré sur le 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 il y a au total trois canaux.

Demande d’invitation de la part du client : en effet le client envoie une requête de deman

Fourniture des services : le serveur envoie le service demandé par un client enregistré après voir reçu l’invitation de sa part. Voici un aperçu de connexion avec trois services fournis par le serveur

Vidéo en UDP (avec VLC player), vidéo en RTP et Messagerie instantanée


Grâce à cette plateforme, le client peut alors communiquer avec le serveur et bénéficier des communication se fait suivant cinq étapes :

montre la figure ci-dessus, il envoie

: le serveur IMS authentifie le client et l’enregistre dans sa base de l est enregistré sur le serveur.

Démarrage du serveur des applications comme iptv pour établir les liens sur les canaux de

: en effet le client envoie une requête de demande

: le serveur envoie le service demandé par un client enregistré après voir reçu l’invitation de sa part. Voici un aperçu de connexion avec trois services fournis par le serveur

, vidéo en RTP et Messagerie instantanée :

Finalement, les deux machines étant configurées, et 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

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 Débian : # ping 10.10.2.2 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 : voici 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

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

Test de l’architecture MPLS-IMS 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

On lance alors la commande à partir des deux bouts de la connexion : le client et le serveur

: # 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 i 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 :


l’architecture MPLS également, il faut maintenant utiliser des paquets d’envoie simples comme le ping par exemple afin de vérifier le passage

: 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

: le client et le serveur :

// 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 i un aperçu de cette capture montrant les paquets ICMP requête et réponse entre

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 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 suite pénaliser la qualité de service. En ce qui concerne les servichoisit trois qui demande une grande gestion de la qualité de service

- Vidéo avec le protocole U- 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 WIZARD du VLC comme suit :

- Lancer VLC


Page 49

On remarque également sur cette figure l’apparition du protocole MPLS dans la trame envoyé

Donc le ping étant réussit de bout en bout, on en conclut ainsi que la connexion est établie et

strements en session au serveur et échanger des services.

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 à lancer, il en a plusieurschoisit trois qui demande une grande gestion de la qualité de service à savoir :

Vidéo avec le protocole UDP à travers la diffusion sur le réseau par le lecteur VLCVidé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.

, 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


On remarque également sur cette figure l’apparition du protocole MPLS dans la trame envoyé

Donc le ping étant réussit de bout en bout, on en conclut ainsi que la connexion est établie et strements en session au serveur et échanger des services.

Le scenario pour atteindre notre objectif de gestion de QOS consiste en fait à lancer trois services le maximum de bande passante et par la

ces à lancer, il en a plusieurs, mais on a

DP à 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.

, le client doit d’abord passer par toutes les étapes de demande d’un par VLC, il faut la configurer à partir du


Page 50

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

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 dans une session mené de plusieurs paramètreessentiellement :

• DELTA (ms) : le temps du retard des trames• BW (kbps) : la bande passante allouée au • Lost : taux de pertes des paquets.• …….etc.

En somme il y a plusieurs paramètreafin de voir la différence des temps entre l’utilisation du BEST EFFORT et de


Page 51

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

ion mené de plusieurs paramètres de gestion de qualité de service dont on site

: le temps du retard des trames. : la bande passante allouée au service.

: taux de pertes des paquets.

plusieurs paramètres 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


On a donc utilisé le protocole RTP et quand la trame passe dans le backbone MPLS elle est

de streaming qui sont générer de gestion de qualité de service dont on site

et on choisit de visualisé les DELTA times afin de voir la différence des temps entre l’utilisation du BEST EFFORT et de

7. Test de la qualité de service IMS gérée avec BEST EFFORT Ainsi, les services étant lancés, on

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 EFFORTmauvaise 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 mauvaise qualité de serviceavec WIRESHARK et sur lequel il y’a les paramètres déjà cité


Page 52

Test de la qualité de service IMS gérée avec BEST EFFORT

, les services étant lancés, on peut maintenant faire une étude sur la qualité de service du , 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ésultatmauvaise 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 :

tte mauvaise qualité de service, voici un aperçu deavec WIRESHARK et sur lequel il y’a les paramètres déjà cité :


Test de la qualité de service IMS gérée avec BEST EFFORT :

peut maintenant faire une étude sur la qualité de service du , on n’a pas encore utilisé un protocole de gestion de la QOS comme

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

, voici un aperçu des streaming capturé

On 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 à

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 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 IP. Cette classification doit se faire sur les routeurs de bordures (l'entrée du réseau.


Page 53

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

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.

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

caractériser sous forme de classes. Chaque classe est identifiée par une tête IP. Cette classification doit se faire sur les routeurs de bordures (


utiliser DIFFSERV afin de diminuer le DELTAS max.

Les routeurs utilisés jusqu'à présent sont configurés pour utiliser BEST EFFORT, nous allons donc

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

caractériser sous forme de classes. Chaque classe est identifiée par une tête IP. Cette classification doit se faire sur les routeurs de bordures (edge router) à


Page 54

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 55

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

aaaa.... Filtrage des fluxFiltrage des fluxFiltrage des fluxFiltrage 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 56

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 57

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

bbbb.... Classification du traficClassification du traficClassification du traficClassification 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 58

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 59

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

cccc.... Création d'une politique de serviceCréation d'une politique de serviceCréation d'une politique de serviceCré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 60

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 61

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

9. Test de l’Amélioration de la qualité de service avec DIFFSERV

L’utilisation de DIFFSERV sur le différenciant chaque trafic et le traiter à partqui montre que la qualité de la vidéo

Il reste à vérifier que le paramètrele mieux, c’est le paramètre DELTABEST EFFORT on avait DELTA égaleest devenu égale a 44 ms. La capture suivante montre le nouveau DELTA


Page 62

Test de l’Amélioration de la qualité de service avec DIFFSERV

de DIFFSERV sur le protocole MPLS a permis une meilleure

différenciant chaque trafic et le traiter à part, le résultat de ce traitement est illustré pvidéo IPTV avec RTP est meilleure que celle de VLC

paramètre qu’on surveillait avant pour la qualité des services a changé vers DELTA : le temps de retard des paquets UDP RTP avec IPTV

égale a 397 ms alors qu’après traitement avec DIFFSERV le DELTA a 44 ms. La capture suivante montre le nouveau DELTA.


Test de l’Amélioration de la qualité de service avec DIFFSERV :

gestion de service en de ce traitement est illustré par la capture suivant

IPTV avec RTP est meilleure que celle de VLC :

qu’on surveillait avant pour la qualité des services a changé vers temps de retard des paquets UDP RTP avec IPTV .Alors avec

nt avec DIFFSERV le DELTA


Page 63



Page 64

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 65

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 66

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

Documents

Rapport Projet Dev