Problématique de gestion d'un réseau multiservices et son impact sur la GOS. Cas de la gécamines Lubumbashi et Kolwezi.

SEPTEMBRE 2019

PROBLEMATIQUE DE GESTION D'UN RESEAU MULTISERVICES ET SON IMPACT SUR LA QOS

(CAS DE LA GECAMINES LUBUMBASHI ET KOLWEZI)

Par : MPUNGU KABIOLA Delly

Travail présenté et défendu en vue de l'obtention du grade d'ingénieur en sciences informatiques

Option : Réseaux et télécommunication

I

PROBLEMATIQUE DE GESTION D'UN RESEAU MULTISERVICES ET SON IMPACT SUR LA QOS

(CAS DE LA GECAMINES LUBUMBASHI ET KOLWEZI)

Par : MPUNGU KABIOLA Delly Dirigé par : Prof Jean-Marie KANDA Codirigé par : Master Daniel KATUAL

SEPTEMBRE 2019

I

EPIGRAPHE

« Les applications multimédias représentent aujourd'hui un fort potentiel de développement, parmi ces applications, la téléphonie et le streaming vidéo imposent des contraintes fortes sur le délai de transmission et le synchronisme, ces contraintes n'ont pas étés prises en compte dans la conception initiale des réseaux informatiques que nous utilisons aujourd'hui. »

MPUNGU KABIOLA Delly

II

DEDICACE

« A toute la communauté scientifique, plus particulièrement aux ingénieurs en réseaux et télécommunications »

Je dédie ce travail.

MPUNGU KABIOLA Delly

III

REMERCIEMENTS

Partant de ce travail scientifique qui sanctionne la fin de notre deuxième cycle à la faculté des sciences informatiques, département des réseaux et télécommunications, il est de l'importance capitale pour nous d'exprimer les sentiments de notre profonde gratitude envers tous ceux qui ont eu à nous donner un coup de main de près ou de loin durant notre parcours à l'Université Protestante de Lubumbashi (UPL)

Nous tenons sincèrement à dire merci à DIEU tout puissant pour la grâce qu'il nous a faite tout au long de notre cursus académique.

Nous disons grandement merci à notre directeur, monsieur le professeur Jean-Marie KANDA pour ses conseils, encouragements et orientation dans l'élaboration de ce travail malgré ses multiples grandes occupations.

Nos remerciements vont aussi à l'endroit du très cher Master Daniel KATUAL, malgré ses multiples occupations professionnelles, il a quand-même accepté la codirection de ce travail scientifique, son aide consistante, ses conseils judicieux et ses remarques objectives nous ont été fort appréciables dans l'élaboration de ce mémoire ; Qu'il en trouve l'expression de notre profonde gratitude.

Nos remerciements les plus sincères s'adressent aux membres du corps professoral et administratif de l`Université Protestante de Lubumbashi, pour la richesse et la qualité de leur enseignement et pour les efforts qu'ils déploient en vue d'assurer à leurs étudiants une formation actualisée. Je m'adresse plus particulièrement au Professeur Blaise FYAMA, le doyen de la faculté des sciences informatiques, pour sa bonne gestion de la faculté, et pour toutes les reformes qu'il a initiées en matière de rédaction de nos travaux, et dont nous avons su tirer grand profit dans la réalisation de ce travail.

A mes très chers et aimable parents, Marcel KABIOLA, Alphonsine MPUNGU et Marie NGALULA, que ce travail soit le fruit de vos devoirs et obligations inoubliables, de vos sacrifices et Amour sans cesse envers votre fils MPUNGU KABIOLA Delly.

Nous tenons à exprimer nos sincères gratitudes à notre grand Frère Dieudonné MBAYI et sa femme Clarisse TSHILEMBA pour leur accueil chaleureux dans leur maison à Lubumbashi, leur soutien matériel, financier, spirituel et moral qui nous ont tant servis tout au long de notre parcours estudiantin, que le Dieu tout puissant vous bénisses richement.

Nous remercions également tous nos frères et soeurs, nous citons : Sylvie TSHANDA, Excellent NDAYE, Alpho MPUNGU, Ruth NKAYA, Jacques SOMBAMANYA, Jeannette MULAMBA, Marie MADIYA TSHILANDA, Marcel KABIOLA, Hélène TSHAMA, Sympho KABAMBA, Paulin

KABEMBA, Dieudonné KAMUANGA, Jonathan KALELA, Josué DITALALA, Christian KABULETA, Théo MWAMBA, Jean-Luc KABUYA, Trésors KABIOLA etc.

Nos remerciements s'adressent également à tous les amis, collègues de promotion et ingénieurs à savoir : HOMAR BONGO BONANZA, MWAMBA MWAMBA Martin, MBUYI KABULA Guelord-Staze, MUKANYA Zaphenath, KABASELE MFWAMBA Dominique, BUKASA KAMPOYI Robert, KANDA ANASTHAN Elie, KABEYA KALALA Nicolas, Le groupe Dièse (#), Mr MWAMBA KAYEMBE Michée, Mr Nicolas MUSUBE, Mr Blaise SABU.

Nous ne pouvons pas passer sans remercier nos neveux et Nièces : Rodrigue KAISA, Magali Kelly KANKU MUKALA, Eliel NDAYE, Précieux et précieuse MBAYI etc.

Nous ne passerons pas sans citer notre premier conseillé et collègue scribe Célestin NKUNZA et tous ceux qui ont eu à contribuer de loin ou de près avec leur concours morale, matériel ou spirituel pour l'élaboration de ce travail, trouvez ici nos sincères remerciements.

MPUNGU KABIOLA Delly

V

LISTE DES FIGURES

Figure 1. 1. Perception de la QOS dans le réseau 8

Figure 1. 2. Aspect tridimensionnelle de la qualité de service 9

Figure 1. 3. Besoins des applications en terme de délai et bande passante 10

Figure 1. 4. Principe général du modèle à intégration de service 14

Figure 1. 5. Architecture d'un routeur INTSERV 15

Figure 1. 6. Architecture DIFFSERV 17

Figure 1. 7. Qualité de service requise pour les applications 20

Figure 1. 9. La structure de l'entête IP 21

Figure 1. 10. Le détail du champ TOS 22

Figure 1. 11. Entête IP 25

Figure 1. 12. Changement de l'entête TOS d'IPV4 vers COS en IPV6 25

Figure 2. 1. Aperçu de L'architecture réseau de Lubumbashi 30

Figure 2. 2. Architecture du réseau de la Gécamines 35

Figure 3. 1. Schéma de principe du modèle DIFFSERV 39

Figure 3. 2. Architecture d'un routeur DIFFSERV de bordure 40

Figure 3. 3. Diagramme de cas d'utilisation DIFFSERV 41

Figure 3. 4. Diagramme d'activités du modèle DIFFSERV 43

Figure 3. 5. Diagramme de séquence (Classifier paquets) 44

Figure 3. 6. Diagramme de séquence (Conditionnement du trafic) 44

Figure 3. 7. Diagramme de séquence (Gérer file d'attente) 45

Figure 3. 8. Diagramme de séquence (Ordonnancer trafic) 45

Figure 3. 9. Architecture d'un routeur INTSERV 47

Figure 3. 10. Diagramme de cas d'utilisation INTSERV 48

Figure 3. 11. Diagramme d'activités du modèle INTSERV 50

Figure 3. 12. Fonctionnement du protocole RSVP 51

VI

Figure 3. 13. Diagramme de séquence (Fonctionnement RSVP) 52

Figure 3.15. Diagramme de séquence (Processus de routage RSVP) 53

Figure 3.16. Diagramme de séquence (Evaluation du service et réservation) 53

Figure 4. 1. Architecture réseau 56

Figure 4. 2. Architecture réseau de la maquette 59

VII

LISTE DES TABLEAUX

Tableau 1. 1. Les exigences de quelques applications en termes de la qualité de service 13

Tableau 1. 2.Récapitulatif des priorités de service DiffServ 19

Tableau 1. 3. Les correspondances des différentes combinaisons de priorité 22

Tableau 4. 1. Exigences en métriques de qualité de service des flux multimédia 57

Tableau 4. 2. L'environnement matériels et logiciels 58

Tableau 4. 3. Plan d'adressage 59

VIII

LISTE DES ABREVIATIONS

RSVP : RESSOURCE RESERVATION PROTOCOL

INTSERV : INTEGRATED SERVICE

DIFFSERV : DIFFERENTIATED SERVICE

QOS : QUALITY OF SERVICE

TOS : TYPE OF SERVICE

COS : CLASS OF SERVICE

VOIP : VOICE OVER INTERNET PROTOCOL

UIT : UNION INTERNATIONALE DE TELECOMMUNICATION

DSCP : DIFFSERV CODE POINT

LAN : LOCAL AREA NETWORK

WAN : WIDE AREA NETWORK

TCP : TRANSMISSION COMTROL PROTOCOL

UDP : USER DATAGRAM PROTOCOLE

FTP : FILE TRANSFERT PROTOCOLE

GS : GUARANTED SERVICE

CL : CONTROLED LORD

EF : EXPEDITED FORWADING

AF : ASSURED FORWADING

BE : BEST EFFORT

OSI : OPEN SYSTEME INTERCONNEXION

BA : BEHAVER AGGREGATE

PHB : PER HOPE BEHAVIOUR

IHL : INTERNET HEADER LENGTH

TTL : TIME TO LIFE

DNS : DOMAIN NAME SERVICE

DHCP : DINAMIC HOST CONFIGURATION PROTOCOLE

IETF : INTERNET ENGINEERING TASK FORCE

LLQ : LOW LATENCY QUEUING

RED : RANDOM EARLY DETECTION

IX

BIBLIOGRAPHIE

[1] P. B. FYAMA, Seminaire de Methodes et techniques en sciences informatiques, Lubumbashi: UPL, 2019.

[2] P. B. FYAMA, «Cours de genie logiciel dans les réseaux,» UPL, Lubumbashi, 2018.

[3] S. H. KALELA, Cours de Réseau cellulaire et téléphonie sur IP, UPL, Lubumbashi, 2019.

[4] O. Dugeon, Architecture des réseaux pour le controle de la QOS, Paris, 2008.

[5] L. Toumi, (Thèses de doctorat ): Algorithmes et mécanismes pour la qualité de service dans des réseaux hétérogènes;, Institut Nationale polytechnique de Grenoble, 2002.

[6] W. CHAIB, «Gestion de la qualité de serrvice dans le réseau NGN,» Université Kasdi Merbah-Ouargla, Algérie, 2015.

[7] A. A. ALI, «Thèse: Amélioration de la mesure de la bande passante dans un réseau basé sur IP,» Nancy-Université, 2007.

[8] MAWANZA, Mémoir de fin d'étude: Etuse et mise en place de la VoIp à la SCTP.

[9] W. C. e. Y. B. DANIA, «Gestion de la qualité de service dans le réseaux de nouvelle génération,» Algérie, 2015.

[10] M. L. Lamali, Thèse de doctorat: Qualité de service et calculs des chemins dans un réseau inter-domaine multicouches, Ecole doctorale SVT, 2014.

[11] A. D. e. L. Gabriel, « Mise en oeuvre de deux approches standards: Intserv et Diffserv,» UNIVERSITE PIERRE ET MARIE CURIE, Paris, 2007.

[12] O. Dugeon, Architectures des réseaux pour le contôle de la QoS (Institut National Polytech de Toulouse, 2008.

[13] C. Servin, Les réseaux et télécoms (Cours et exercices corrigés), Paris: DUNOD, 2003.

[14] C. servin, Réseaux et télécoms (Cours et exercice corrigés), Paris: DUNOD, 2003.

[15] wikipédia, «Théorie des files d'attentes,» 30 Juillet 2019. [En ligne]. Available: http://fr.m.wikipédia.org. [Accès le 30 Juillet 2019].

[16] J.-L. Montagnier, Construire son réseau d'entreprise, Paris: Eyrolles, 2001.

[17] L. O. e. G. Pujolle, «La téléphonie sur IP,» Eyrolles, Paris.

[18] P. B. FYAMA, Cours de génie logiciel dans les réseaux (Grade 1 RT, UPL), Lubumbashi: UPL, 2018.

[19] P. KABAMBA, Cours de gestion des réseaux et des services, Grade 1 RT, UPL, Lubumbashi: Université Protestante de Lubumbashi, 2018.

X

[20] C. N. ACADEMY, Présentation du routage et de la commutation au sein d'une entreprise, Lubumbashi: CCNA discovery 4.0, 2008.

[21] Internet, «Calculs de la BP pour la voIP».

[22] D. M. V. DROOGENBROECK, «Technologies du multimédia, des télécommunications et de l'internet,» Liège, 2004.

XI

TABLE DES MATIERES

cFJPIÇRflPHcFJ 1

DEDICACE II

REMERCIEMENTS III

LISTE DES TABLEAUX VII

LISTE DES ABREVIATIONS VIII

BIBLIOGRAPHIE IX

TABLE DES MATIERES XI

INTRODUCTION GENERALE 1

CHAPITRE 1 : CONSIDERATION GENERALE SUR LA QUALITE DE SERVICE

DANS UN RESEAU 6

1.1. INTRODUCTION 6

1.2. DEFINITION DES CONCEPTS 6

1.2.1. UN SERVICE 6

1.2.2. LA QUALITE DE SERVICE 6

1.2.3. LA QUALITE DE SERVICE VUE PAR LE GESTIONNAIRE DU RESEAU 7

1.2.4. LA QUALITE DE SERVICE VUE PAR L'EXPLOITANT DU RESEAU 7

1.3. CRITERES D'EVALUATION DE LA QUALITE DE SERVICE DANS UN

RESEAU 9

1.4. TYPE DE TRAFICS SUR LE RESEAU 12

1.4.1. LES APPLICATIONS ELASTIQUES 12

1.4.2. LES APPLICATIONS NON ELASTIQUES 12

1.5. LE MODELE A INTEGRATION DES SERVICES (INTSERV) 13

1.5.1. PRESENTATION 13

1.5.2. PRINCIPE DU MODELE INTSERV 14

1.5.4.1. LE SERVICE BEST EFFORT 16

1.5.4.2. LE SERVICE CONTROLED LOARD 16

1.5.4.3. LE SERVICE GUARANTI 16

1.6. LE MODELE A DIFFERENTIATION DES SERVICES (DIFFSERV) 16

1.6.1. PRESENTATION DE DIFFSERV 16

1.6.2. ARCHITECTURE DIFFSERV 17

1.6.3. CLASSIFICATION DES SERVICES DIFFSERV 18

1.6.3. LES DIFFERENTES METHODES DE GESTION DE LA QOS 20

1.7. NOTION D'EN-TETE IP 20

1.7.3. LE PROTOCOLE IP 21

1.7.3.1.1. STRUCTURE DE L'EN-TETE 21

1.7.3.1.2. DEFINITION DE DIFFERENTS CHAMPS 21

XII

1.7.3.1.3. DIFFERENCE ENTRE ENTETE IPV4 ET IPV6 24

CHAPITRE 2 : ETAT DE FONCTIONNEMENT DU RESEAU DE LA GECAMINES

26

2.1. INTRODUCTION 26

2.2. PRESENTATION GENERALE DE L'ENTREPRISE 26

2.3. OBJECTIFS DE LA GECAMINES 28

2.4. PRESENTATION DU DEPARTEMENT INFORMATIQUE 28

2.5. PRESENTATION DES DONNEES DU LAN DE LUBUMBASHI 30

2.5.1. PRESENTATION DE L'EXISTANT 30

2.5.2. COMPOSITION MATERIELLE ET ACCESSOIRES DIVERS 31

2.5.3. CALCULS DE LA VOLUMETRIE ET DU TEMPS DE TRANSMISSION DANS

LE LAN DE LUBUMBASHI 32

2.6. L'ARCHITECTURE RESEAU DE LA GECAMINES (LUBUMBASHI et

KOLWEZI) 34

2.6.1. ANALYSE DE LA QUALITE DE SERVICE DANS LE LAN DE LUBUMBASHI

ET DE KOLWEZI 35

2.6.1.1. CALCUL DE LA VOLUMETRIE DANS LE SITE DE KOLWEZI ET DU

TEMPS DE TRANSMISSION 36

2.6.2. IDENTIFICATION DES BESOINS DES UTILISATEURS 36

2.6.2.1. BESOINS FONCTIONNELS 36

2.6.2.2. BESOINS NON FONCTIONNELS 37

2.6.3. PRESENTATION DES POINTS FAIBLES ET FORT DU RESEAU 37

2.6.3.1. POINTS FORT DU RESEAU 37

2.6.3.2. POINTS FAIBLE DU RESEAU 37

2.6.3.3. PROPOSITION DE LA SOLUTION 38

CHAPITRE 3 : ANALYSE FONCTIONNELLE DU MODELE INTSERV ET

DIFFSERV 39

3.1. INTRODUCTION 39

3.2. MODELE A DIFFERENCIATION DE SERVICE (DIFFSERV) 39

3.2.1. PRESENTATION ET PRINCIPE DE FONCTIONNEMENT 39

3.2.2. PRESENTATION D'UN ROUTEUR DIFFSERV DE BORDURE 39

3.2.3. LE DIAGRAMME DE CAS D'UTILISATION 40

3.2.4. DIAGRAMME D'ACTIVITE (DiffServ) 43

3.2.5. LES DIAGRAMMES DE SEQUENCE CLASSIFIER PAQUET 43

3.3. LE MODELE INTSERV/RSVP 46

3.3.1. PRESENTATION ET PRINCIPE DE FONCTIONNEMENT 46

3.3.2. ARCHITECTURE D'UN ROUTEUR INTSERV/RSVP 46

3.3.3. ANALYSE FONCTIONNELLE DU MODELE INTSERV/RSVP 47

3.3.3.1. DIAGRAMME DE CAS D'UTILISATION 47

XIII

3.3.3.2. DIAGRAMME D'ACTIVITES INTSERV 50

3.3.3.3. LE PROCESSUS DE RESERVATION (RSVP) 51

3.3.3.3.1. PRESENTATION 51

3.3.3.3.2. PRINCIPE DE FONCTIONNEMENT 51

3.3.3.3.4. LE PROCESSUS DE ROUTAGE 52

3.1.1.1.1. DIAGRAMME DE SEQUENCE EVALUATION DE SERVICE ET

RESERVATION DE LA BANDE PASSANTE 53

3.1.1.1.2. CONCLUSION PARTIELLE 54

CHAPITRE 4 : OPTIMISATION DE LA QUALITE DE SERVICE DANS LE

RESEAU DE LA GECAMINES 55

4.1. INTRODUCTION 55

4.2. INGENIERIE D'OPTIMISATION DE LA QUALITE DE SERVICE 55

4.3. CREATION DE LA MAQUETTE 58

4.3.1. PLAN DE CONFIGURATION 58

4.3.2. L'ENVIRONNEMENT MATERIELS ET LOGICIELS 58

4.3.3. ARCHITECTURE RESEAU 58

4.3.4. PLAN D'ADRESSAGE 59

4.3.5. CONFIGURATION DE LA CLASSIFICATION DES FLUX 61

4.3.6. CONFIGURATION DE L'ALGORITHME D'ORDONNANCEMENT LLQ 63

4.3.7. CONFIGURATION DU PROTOCOLE RSVP 64

CONCLUSION GENERALE 65

1

INTRODUCTION GENERALE

Le réseau informatique est un ensemble d'équipements interconnectés entre eux en vue de permettre la communication, il constitue le facteur principal et incontournable de production dans une entreprise ; ce domaine est en évolution perpétuelle car chaque jour qui passe apporte un nouvel élément à la connaissance de l'homme et cette connaissance le pousse à comprendre, découvrir et développer les facteurs qui ont lieu dans son entourage dans le but de garantir un bon fonctionnement et un bon avenir du système d'information.

Jadis chaque type de trafic avait son propre réseau dédié et taillé sur mesure, mais aujourd'hui grâce à l'évolution des capacités des réseaux, le traitement automatisé de l'information a considérablement évolué depuis une soixantaine d'années grâce à l'avènement de l'internet (un réseau gigantesque) le protocole IP a vu le jour et grâce à ce protocole les différents flux de trafic sont regroupés sur un seul et même support que constituent les réseaux IP, le débit ne cesse de grimper et les réseaux actuels d'entreprises sont désormais multiservices ; cette centralisation simplifie grandement les taches des administrateurs car il y'a une seule infrastructure à gérer.

La taille des réseaux ne cesse de grandir du jour le jour et l'importance de celle-ci dans le monde de l'entreprise prend une place prépondérante grâce à la démocratisation de l'internet, raison pour laquelle un réseau d'entreprise d'aujourd'hui vu qu'il est en mode paquet doit assurer l'échange des types variés des trafics tels que les fichiers de données, les courriels, la téléphonie sur IP, les applications vidéos pour les domaines d'activités multiples et ces types différent des trafics implémentés au sein d'un même réseau utilisent une même infrastructure.

Cependant, sans régulation du trafic les réseaux basés sur IP se retrouvent vite saturés car la multiplication des flux provoque l'engorgement des liaisons, il faut donc faire la police pour fluidifier la circulation afin de pouvoir assurer un niveau de service satisfaisant pour les utilisateurs et améliorer les performances d'un réseau, il convient d'envisager une notion nouvelle portant sur la qualité de service.

Ayant observé que l'infrastructure réseau de la Gécamines qui était conçu pour le transport de données est actuellement aussi utilisé pour les flux multimédias, ceci requiert une dose passionnée de recherche qui impose que l'acheminement de ces flux de trafics soit assuré avec une qualité de service maitrisée et acceptable ; voilà la raison de notre sujet intitulé : « Problématique de gestion d'un réseau multiservice et son impact sur la qualité de service » (cas de la Gécamines Lubumbashi et Kolwezi).

2

Lors de notre formation dans le cours de génie des réseaux, nous nous sommes plus intéressés sur l'évaluation des performances des réseaux. Par la soif d'approfondir notre connaissance dans cette matière, nous avons fait de ceci notre champ de batail.

Le présent travail étant purement scientifique sera une documentation sur base de laquelle des futurs chercheurs pourraient se référer pour réaliser une oeuvre scientifique.

Nous ne prétendons pas être le premier à aborder ce sujet car tout progrès scientifique est cumulatif et n'est donc pas l'apanage à un seul individu mais plutôt d'un groupe de gens qui révisent, critiquent, ajoutent, élargissent et améliorent. Sûrement, il y a toute une panoplie des chercheurs qui ont eu à écrire sur le même sujet que nous ; ainsi tels sont les personnes qui ont eu à nous précéder dans la recherche :

? KASONGO BABADI Maick UPL, 2017 ; il a parlé sur : Analyse fonctionnelle en vue d'une optimisation d'un système VOIP pour la maintenance de la QoS dans un réseau. (cas de la SNCC)

Dans ce travail, l'auteur s'est penché sur la question de dimensionnement du réseau à partir du réseau existant de la SNCC afin d'améliorer les performances dans l'intégration du système de la VOIP pour assurer une meilleure QoS lors de la communication entre agents.

Notre travail de fin d'étude se démarque de celui de notre prédécesseur sur le fait que nous parlons sur la problématique de gestion d'un réseau multiservices et son impact sur la qualité de service et ensuite nous proposerons quelques pistes de solution pour l'optimisation d'un tel réseau.

? OLIVIER DUGEON (Institut National Polytechnique de Toulouse, 2008) : Architectures des réseaux pour le contrôle de la QoS (Mémoire de fin d'étude)

Ce mémoire d'habilitation à diriger des recherches synthétise le travail de recherche effectué sur un ensemble d'architectures pour contrôler la QoS dans les réseaux en mode paquets.

La démarcation de notre travail avec celui de notre prédécesseur intervient sur le fait que nous parlons sur la problématique de gestion d'un réseau multiservices face à la qualité de service et ensuite nous proposerons quelques pistes de solution pour l'optimisation d'un tel réseau.

3

Se référant aux traités des méthodologies scientifiques, le Professeur Blaise FYAMA a définit la problématique comme étant l'art de poser clairement un problème et de le résoudre en suivant sa transformation dans la réflexion et la démarche scientifique. [1]

Les progrès technologiques permettent de fabriquer des stations de travail et des ordinateurs de bureau de plus en plus rapides et intelligents. La combinaison de stations de travail de plus en plus puissantes à des applications fortement consommatrices de ressources réseau exige une capacité réseau et une qualité de service très fiable.

Le réseau de la Gécamines est un réseau qui transmet un nombre accru d'applications multimédias de divers formats, telles que : les images, images animées, la voix sur IP, les flux vidéo, les e-mails etc. ces différents services partagent une même bande passante disponible ; cela entrainent de congestion de réseau qui se traduit par un ralentissement de temps de réponse, ainsi que par une diminution de la productivité des utilisateurs entre les sites distants du réseau.

D'où, pour mener à bon escient notre étude au sein de ce réseau, notre réflexion se base sur les questions suivantes :

? Quelle démarche scientifique pouvons-nous adopter pour fluidifier facilement le trafic afin d'éliminer la congestion dans le réseau de la Gécamines ?

? Comment optimiser la qualité de service dans un réseau à flux multimédias ?

Telles sont des questions sur lesquelles sera basé le développement de notre travail, ici-bas nous proposons les réponses provisoires à ces questions de la problématique :

? La démarche Network Calculus est une solution nous permettant d'évaluer la qualité de service dans les deux sites de la Gécamines (le LAN de Lubumbashi et celui de Kolwezi) en calculant le temps de réponse du système pour les flux multimédias échangés ;

? Nous allons faire l'analyse fonctionnelle des modèles de la qualité de service dans le réseau (le modèle Intserv et le modèle Diffserv) pour enfin faire un choix judicieux du modèle qui nous permettra d'optimiser la QoS dans ce réseau de la Gécamines entre les sites ciblés.

On appelle méthode scientifique l'ensemble des canons guidant ou devant guider le processus de production des connaissances scientifiques, que ce soit des observations, des expériences, des raisonnements, des calculs théoriques ou appliqués. [1]

4

Pour ce qui cadre avec notre travail, nous avons opté pour l'utilisation de la méthode Network Calculus, elle permet de calculer des bornes sur les délais de d'acheminement ainsi que d'autres paramètres de la qualité de service, son but est d'analyser les comportements critiques du réseau et il s'intéresse pour cela aux performances pire-cas : soit des performances locales telle que la taille maximale d'un buffer au niveau d'un noeud du réseau (Routeur), soit des performances de bout en bout (temps de trajet de bout en bout). [1]

Cette méthode va nous permettre d'évaluer la performance du réseau de la Gécamines en termes de la qualité de service pour enfin garantir une certaine performance dans le service des données, de la voix sur IP et de fournir un ensemble des mécanismes permettant de rendre d'autres services prioritaires par rapport à d'autres, ça relève de l'ingénierie de trafic. Nous allons nous intéresser aux paramètres tels que : le débit, le délai de transit (latence) sur le réseau.

La méthode UP (Unified Processus) avec comme outil UML qui est un langage de modélisation graphique à base de pictogrammes, conçu pour représenter et spécifier les artefacts des systèmes logiciels. [2] Elle va nous permettre d'analyser les fonctionnalités du modèle DIFFSERV (Différentiated service) et le modèle INTSERV (Integrated service) à l'aide des diagrammes UML.

Nous allons utiliser la technique de gestion du réseau, elle nous permet de gérer le réseau de la Gécamines pour garantir une bonne qualité de service pour les flux multimédias etc.

Nous utiliserons aussi la technique d'intégration et de simulation ; elle nous permet d'intégrer l'un des modèles de qualité de service au sein du réseau de la Gécamines après analyse fonctionnelle de ces deux modèles.

Ce présent travail s'applique sur le réseau de la Gécamines et s'étend sur une base temporelle allant du mois d'Avril 2019 au septembre 2019 c'est-à-dire au cours de l'année académique 2018-2019.

A part l'introduction et la conclusion générale, nous avons choisi d'articuler notre étude autour de quatre chapitres principaux en occurrence :

CHAPITRE 1 : CONSIDERATION GENERALE SUR LA QUALITE DE SERVICE DANS UN RESEAU

5

Ce chapitre est consacré à la qualité de service en définissant tout d'abord la notion en tant que telle, puis en présentant les paramètres qui garantissent la qualité de service dans un réseau. Nous exposons de même, les différentes techniques développées par la communauté de recherche, à savoir les modèles à intégration de service « IntServ », puis les modèles à différenciation de service « DiffServ ». Pour chacun de ces modèles, nous détaillons les architectures et les différents services offerts qui permettent d'assurer la qualité de service dans un réseau.

CHAPITRE 2 : ETAT DE FONCTIONNEMENT DU RESEAU DE LA GECAMINE

Ce présent chapitre fera l'objet d'un bref aperçu sur la présentation de la Gécamines, en présentant les différents services utilisés dans le réseau actuellement pour révéler les besoins que présente l'entreprise en termes de qualité de service et enfin proposer une piste qui permettra à l'entreprise de satisfaire ses utilisateurs.

CHAPITRE 3 : ANALYSE FONCTIONNELLE DU MODELE INTSERV ET DIFFSERV

Cette partie du travail sera consacrée à l'analyse des différentes fonctionnalités avancées du modèle DIFFSERV et INTSERV à l'aide des diagrammes UML.

CHAPITRE 4 : OPTIMISATION DE LA QUALITE DE SERVICE DANS LE RESEAU DE LA GECAMINES

Ce chapitre est basé sur l'optimisation de la qualité de service par l'intégration de l'un de modèle de qualité de service au sein du réseau en faisant une simulation de la solution.

Enfin, la conclusion générale résumera les résultats obtenus et donnera quelques perspectives sur des travaux futurs.

6

CHAPITRE 1 : CONSIDERATION GENERALE SUR LA QUALITE DE
SERVICE DANS UN RESEAU

1.1.INTRODUCTION

Nous voici au premier chapitre de notre travail, il s'agit ici de présenter les notions théoriques ayant trait à la qualité de service en définissant tout d'abord la notion en tant que telle, puis en présentant les paramètres qui garantissent la qualité de service dans un réseau.

Nous exposons, de même, les différentes techniques développées par les communautés de recherches, à savoir les modèles à intégration de service « INTSERV », puis les modèles à différenciation de service « DIFFSERV ».

Et pour chacun de ces modèles, nous détaillons les architectures et les différents services offerts qui permettent d'assurer la qualité de service dans un réseau.

1.2. DEFINITION DES CONCEPTS

1.2.1. UN SERVICE

Un service est défini comme étant un produit immatériel émanant de l'activité humaine (prestation), destiné à satisfaire un besoin réel de celui-ci [3]. Ce service doit être disponible.

1.2.2. LA QUALITE DE SERVICE

La qualité de service se définit comme étant l'aptitude exprimant un degré d'excellence d'un service à répondre adéquatement à des exigences et attentes exprimées ou implicites qui visent à satisfaire des usagers [3]

Elle peut en outre se définir comme étant l'ensemble des phénomènes pouvant influencer les performances d'un service qui détermine le degré de satisfaction de l'utilisateur de ce service. [4]

La recommandation E-800 de l'UIT définit la qualité de service par « L'effet global produit par la qualité de fonctionnement d'un service qui détermine le degré de satisfaction de l'usager d'un service » ; plus techniquement, nous proposons une autre définition de la qualité de service : « la qualité de service constitue, pour un élément du réseau (une application, un hôte ou même un routeur), la capacité d'obtenir un certain niveau d'assurance de telle sorte que la fluidité du trafic et les services requis soient au mieux satisfaits » [5].

C'est un concept de gestion qui a pour but d'optimiser les ressources d'un réseau et de garantir de bonnes performances aux applications critiques pour l'entreprise afin de bien rentabiliser l'activité [3].

7

La qualité de service correspond à tous les mécanismes d'un réseau qui permettent de partager équitablement et selon les besoins requis des applications, toutes les ressources offertes, de manière à offrir, autant que possible, à chaque utilisateur la qualité dont il a besoin.

Généralement, cette qualité est axée sur le débit, le délai et la perte des paquets : la téléphonie par Internet a pour but de pouvoir converser en temps réel (facteur du délai) sans entre-coupures engendrées par des délais supplémentaires; télécharger une application volumineuse ne demande pas plus que de disposer d'une assez large bande passante pour récupérer le fichier le plus vite possible (facteur du débit) ; les deux applications sont demandeuses en matière de réception de l'intégralité des paquets (facteur de pertes). [5]

1.2.3. LA QUALITE DE SERVICE VUE PAR LE GESTIONNAIRE DU RESEAU

Le gestionnaire du réseau, quant à lui, sera intéressé par la maîtrise de l'attribution des ressources du réseau en fonction de critères qui définiront la politique d'utilisation du réseau. La priorité sera donnée par exemple à tel ou tel applicatif ou catégorie d'utilisateurs ou liste de serveurs et ce, en fonction de l'heure de la journée et du jour de la semaine. [6]

Le réseau dans son ensemble devra permettre de contrôler l'affectation des ressources parmi les utilisateurs, ce contrôle pouvant se conclure par une facturation.

1.2.4. LA QUALITE DE SERVICE VUE PAR L'EXPLOITANT DU RESEAU

L'exploitant du réseau a un autre objectif qui ressort de la qualité de service offerte par celui-ci et qui y-concourt. Cet objectif est de veiller à ce que les ressources dont dispose l'infrastructure telle que les commutateurs, routeurs, liaisons, soient constamment utilisées au mieux. [6]

Pour un maximum de fiabilité, la qualité de service requiert la coopération de toutes les couches actives du réseau ainsi que celle de chaque élément du réseau, de bout en bout

8

Figure 1. 1. Perception de la QOS dans le réseau

Nous pouvons considérer la qualité de service comme un aspect tridimensionnel basé sur trois composantes à savoir:

V' une composante étendue

V' un modèle de contrôle et

V' une garantie de transmission [7]

1. Par la composante étendue : on définit les limites de services de QoS, nous pouvons citer par exemple la réservation de ressources d'un flot par le protocole RSVP (Resource Reservation Protocol). La réservation s'effectuera entre les hôtes pour délivrer un niveau spécifié de qualité de service.

2. Par le modèle de contrôle : on décrit la granularité, la durée et l'emplacement du contrôle des requêtes de qualité de service. Il est alors nécessaire de disposer d'un ensemble flexible de politiques, de pouvoir éviter ou empêcher des failles de qualité de service, etc. Nous pouvons citer à titre d'exemple la technique de contrôle d'admission des flots à l'intérieur d'un réseau, les mécanismes de gestion de files d'attente, etc.

3. La garantie de transmission est accentuée par la mesurabilité qui consiste à pouvoir disposer de moyens permettant le contrôle des performances du réseau. La performance

9

d'un réseau est évaluée selon le débit et délai de transmission, la disponibilité de la bande passante offerte, le taux de pertes des paquets, etc.

Figure 1. 2. Aspect tridimensionnelle de la qualité de service

1.3.CRITERES D'EVALUATION DE LA QUALITE DE SERVICE DANS UN RESEAU La notion de qualité de service est en général traduite en termes de critères quantifiables de performance des transmissions des différents services. Ces critères de QoS (parfois appelés aussi métriques, ou paramètres) s'appuient sur l'analyse des flux individuels dans le réseau et sont généralement évalués de bout en bout, c'est-à-dire entre la source et la destination. [7]

Les critères d'évaluation de la QoS sont les suivants :

? La bande passante,

? Le délai de transmission (la latence),

? La gigue,

? Le taux de perte.

1. La bande passante : Il s'agit du taux de transfert maximum pouvant être maintenu entre la source et la destination.

2. Le délai de transmission : se traduit par le temps écoulé entre l'émission du paquet par la source et sa réception à l'arrivée par le destinataire; Il se compose de :

? Délai de traitement : c'est le temps que prend le routeur pour examiner le paquet, le déplacer de l'interface d'entrée, et le mettre dans la file d'attente de l'interface de sortie.

10

y' Délai de mise en file d'attente : C'est le temps que le paquet passe dans la file d'attente de sortie du routeur. Il dépend de nombre des paquets déjà dans la file, de la bande passante, de l'interface de sortie, ainsi que du mécanisme de file d'attente adopté.

y' Délai de sérialisation : c'est le temps écoulé pour placer la trame sur le support de transmission.

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

Figure 1. 3. Besoins des applications en terme de délai et bande passante

Source : Thèse de Doctorat de l'Institut National Polytechnique de
Grenoble : Algorithmes et mécanismes pour la qualité
de service dans des réseaux hétérogènes, par Leila TOUMI, 2002

3. La gigue

Elle désigne la variation du délai de bout en bout au cours de la transmission. Une trop forte gigue affecte en particulier les flux multimédias temps-réel en détruisant les relations temporelles des trains de données transmises régulièrement par le flux multimédia, entravant ensuite la compréhension du flux par le récepteur.

4. Le taux de perte des paquets

11

Ce paramètre représente le pourcentage des unités de données qui ne peuvent pas atteindre leur destination dans un intervalle de temps spécifique. Cette perte de paquets aura lieu lorsque le routeur manque d'espace dans le buffer d'une interface, ainsi lorsque la file d'attente de sortie d'une interface particulière est saturée, les nouveaux paquets qui seront dirigés vers cette interface vont être rejetés.

Pour améliorer la qualité de service dans un réseau il faut effectuer : ? La gestion de la bande passante :

Sur le réseau WAN (Wide Area Network) de l'entreprise, la ressource en bande passante est bien plus contraignante que sur le LAN. Une application gourmande en bande passante, telle qu'une application de messagerie ou de transfert de fichiers, peut donc rapidement compromettre la qualité de service (QoS) des applications critiques, comme les progiciels de gestion intégrés ou les bases de données. Par exemple, une session FTP peut parfaitement monopoliser 100 % de la bande passante disponible ; TCP fonctionnant en mode «premier arrivé premier servi», les autres applications n'ont plus alors qu'à attendre le téléchargement se termine pour retrouver une qualité de service normale. [7]

? La réduction de la latence :

La latence est le temps mis par un paquet pour parcourir le trajet source - destination. En mettant en application la QoS, la latence peut être réduite en donnant aux paquets appartenant aux clients les plus importants la priorité dans les files d'attentes des routeurs, de sorte que dès qu'un paquet prioritaire arrivera au routeur, il soit placé en tête dans la file d'attente de celui-ci. [4]

? La réduction de la Gigue :

La gigue est la variation de latence constatée par le récepteur des paquets. Par exemple, si une source envoie des paquets toutes les 30ms et que ceux-ci sont reçus par le récepteur à intervalles de 30ms, la gigue est de zéro. Si la variance entre deux intervalles est différente de zéro, alors on dira que le réseau comporte une gigue.

? La réduction du nombre de paquets perdus :

La perte de paquets force beaucoup d'applications et de protocoles à renvoyer des paquets qui ont été déjà envoyés. Ceci retarde bien sûr la transmission, d'autant plus qu'un certain temps est nécessaire avant que la perte de paquets ne soit décelée.

12

Une méthode pour éviter la perte de paquets serait de s'assurer qu'un noeud du réseau a la capacité d'envoyer des données plus rapidement qu'il ne les reçoit. Cependant, ce n'est pas vraiment une option envisageable car elle serait trop onéreuse. [8]

La perte de paquets peut être traitée de différentes manières par des applications et/ou des protocoles réseau :

? En utilisant TCP, des paquets perdus sont renvoyés par le protocole jusqu'à ce que le récepteur notifie que les paquets ont été bien reçus. En utilisant cette méthode, le même paquet peut traverser des parties du réseau plusieurs fois.

? Une autre option serait l'utilisation d'UDP à la place de TCP et appliquer une autre méthode de traitement pour les paquets perdus. [8]

1.4. TYPE DE TRAFICS SUR LE RESEAU

Il existe deux principales catégories de trafic qui traversent couramment les réseaux :

? Les applications que nous qualifions d'élastiques, caractérisées par une insensibilité au métrique « temps » (telles que les e-mails); ce type de trafic devient alors plus «gourmand » en terme de débit ;

? Les applications moins sensibles en débit mais exigeantes en délai, que nous qualifions de non-élastiques ; la vidéoconférence et la téléphonie par Internet en sont les exemples les plus répandus. [9]

1.4.1. LES APPLICATIONS ELASTIQUES

Les flots ou les applications élastiques sont connus pour leur tolérance aux délais et à leurs variations. Les applications qui génèrent du trafic élastique peuvent donc adapter le taux de génération de leurs paquets en fonction des conditions du réseau. Les applications telles que les transferts de fichiers, le courrier électronique, la connexion à un terminal distant, etc. sont classées dans la catégorie des flots élastiques. [5]

Les besoins de performance pour des applications élastiques sont donc plutôt orientés vers les débits (nécessité de bande-passante) et l'intolérance aux pertes. Par ailleurs, selon les applications, les délais sont plus ou moins importants pour garantir la qualité de service de ces flux.

1.4.2. LES APPLICATIONS NON ELASTIQUES

13

Les flots non-élastiques sont caractérisés par la non-adaptation de leurs trafics vis-à-vis des conditions du réseau sur lequel ils circulent. Pour ces applications, chaque paquet qui est émis doit arriver à destination avec un délai infinitésimal : c'est pourquoi on appelle aussi ces applications, des applications en temps-réel. [5]

La vidéo-conférence, la téléphonie sur Internet mais aussi les jeux en réseaux sont les exemples les plus répandus d'applications temps-réel.

Voici le tableau qui résume les exigences de quelques applications en termes de la qualité de service :

Tableau 1. 1. Les exigences de quelques applications en termes de la qualité de service

Services Délai Gigue Bande passante						Fiabilité
Email	-	-	V'		V'
Transfert de fichiers	-	-	V'		V'
Audio à la demande	-	V'	V'		V'
Vidéo à la demande	-	V'	V'		-
Téléphonie sur IP	V'	-	-		-
Vidéoconférence	V'	V'	V'		-

1.5.LE MODELE A INTEGRATION DES SERVICES (INTSERV)

1.5.1. PRESENTATION

Le modèle à intégration de service (autrement appelé hard QOS) est un modèle qui consiste à réserver les ressources pour les différents types de flux à l'aide de son protocole RSVP ; ce modèle propose de séparer le trafic par flux. [10]

Le protocole RSVP est un protocole de signalisation qui alloue dynamiquement la bande passante et garantit un délai pour certaines applications ; ce qui le rend particulièrement efficace pour le service de la voix sur IP [11].

Ce modèle a pour objectif d'offrir un service semblable sur la couche réseau d'Internet. Le but est donc de pouvoir « améliorer » le réseau Internet et d'en faire un réseau à intégration de services. Il a fallu en effet pouvoir différencier l'utilisation de la bande passante disponible entre les flots multimédias.

14

Les besoins requis par chacun de ces types de flots n'étant pas les mêmes, le modèle INTSERV a défini un ensemble de classes de services qui, implémentées au sein des routeurs, devraient allouer aux flots une certaine qualité de service, à chaque traversée des routeurs, pour les acheminer jusqu'à destination avec cette qualité de service. [10]

1.5.2. PRINCIPE DU MODELE INTSERV

Le principe du modèle INTSERV repose sur deux fondements à savoir :

? Tout d'abord, le réseau doit être contrôlé et soumis aux mécanismes de contrôle d'admission des flux ;

? La nécessité de disposer de mécanismes de réservation de ressources pour obtenir différents services. Pour cela, l'émetteur envoie une requête de réservation de bande passante qui doit être acceptée par l'ensemble des équipements qui seront traversés par les flux. Le protocole utilisé est le RSVP (Ressource reSerVation Protocol) [5]

Figure 1. 4. Principe général du modèle à intégration de service

1.5.3. ARCHITECTURE D'UN ROUTEUR INTSERV

15

Figure 1. 5. Architecture d'un routeur INTSERV Chaque routeur INTSERV est ainsi constitué des éléments suivants :

V' le classificateur (classifier) accueille les paquets en provenance du module de routage et détermine leur appartenance ainsi que leur type. Par exemple, le classificateur va devoir détecter si les paquets ont besoin ou non d'une réservation, s'ils sont ou non porteurs d'une réservation, etc.

V' L'ordonnanceur (scheduler) reçoit les paquets du module précédent et gère leur retransmission en utilisant des files d'attente. Tous les paquets qui seront classés par le classificateur et appartenant à une même classe seront traités de la même manière par l'ordonnanceur.

V' Le contrôleur d'admission (admission controller) vérifie s'il est capable de garantir la qualité de service requise par un flot et s'il y a suffisamment de ressources disponibles au moment de l'établissement d'une réservation ;

V' un démon du protocole RSVP est en permanence en communication avec les différents composants du routeur. A partir de la requête formulée par une application, il fournit les informations au contrôle de trafic de chacun des routeurs qui appartiennent au flot et récupère la réponse du module de contrôle d'admission. [5]

1.5.4. LES CLASSES DE SERVICE INTSERV

Le modèle INTSERV a rendu l'Internet un réseau à intégration de services en distinguant deux classes de services supplémentaires par rapport au service traditionnel sans qualité (Best-effort). Ses nouveaux services sont :

16

? la classe à charge contrôlée communément appelée « Controlled-Load Service » où les performances reçues sont celles d'un réseau peu chargé ; et

? la classe de service garanti communément appelée « Guaranteed Service » où l'application qui demande le service possède l'assurance que les performances du réseau vont rester celles dont elle a besoin.

1.5.4.1.LE SERVICE BEST EFFORT

Le service dit « au-mieux » (Best-Effort, ou BE) ne garantit aucun critère de qualité de service : ni le délai de transmission, ni l'absence de pertes de paquets, ni l'absence de gigue ne sont considérés pour acheminer les flots de diverses natures. Ce service n'est évidemment pas approprié pour les flux multimédia qui transportent des informations à délivrer en temps réel. Il peut toutefois servir pour le transport de données. [5]

1.5.4.2.LE SERVICE CONTROLED LOARD

Le service à charge contrôlée (Controlled-Load, ou CL) effectue une différenciation entre les trafics et leur attribue des codes de priorité en fonction de la sensibilité des applications. Ce service est plus adéquat que le best-effort pour les applications multimédia plutôt adaptatives très sensibles à la congestion dans le réseau. [5]

Il offre un service proche de celui présenté par le best-effort lorsque celui-ci se trouve particulièrement dans des conditions de réseaux non congestionnés. La garantie est donc fournie pour le débit. Mais contrairement au best-effort, le service de charge contrôlée ne détériore pas la qualité du flot lorsque le réseau est surchargé.

1.5.4.3.LE SERVICE GUARANTI

Le service garanti (Guaranteed Service, ou GS) se défini comme étant « un service qui doit assurer de fermes garanties, de telle sorte que le délai de bout en bout mesuré sur les paquets d'un flot n'excède pas une certaine limite ». La classe de service garanti permet de même une garantie de bande-passante. Le service garanti livre les données (applications) en fonction des paramètres négociés et de la classe de service demandée. [5]

1.6.LE MODELE A DIFFERENTIATION DES SERVICES (DIFFSERV)

1.6.1. PRESENTATION DE DIFFSERV

Le modèle à différentiation de service (Diffserv) aussi appelé soft Q.o.S est un modèle qui a été définie par l'IETF et conçu pour fonctionner sur la couche réseau du modèle OSI ou

17

la couche Inter-Réseau (Internet) du modèle TCP/IP, il permet de séparer le trafic par classes contrairement au modèle à intégration des service (Intserv) qui procédait à une séparation de trafic par flux ; de ce fait les routeurs qui exécutent Diffserv traitent tous les paquets d'une même manière sans distinction d'émetteur et de récepteur. [11]

Il se base sur le champ TOS d'IPv4, redéfini par l'IETF en champ DS (DiffServ) pour effectuer la classification. Dans l'IPv6, le champ utilisé par DiffServ est le TC. Le RFC 2475 utilise le terme de BA (Behaviour Aggregate) plutôt que de classe de trafic.

1.6.2. ARCHITECTURE DIFFSERV

Figure 1. 6. Architecture DIFFSERV

Légende :

? Domaine DiffServ (DS domain)

Un domaine un ensemble de noeuds (hôtes et routeurs) administrés de façon homogène et qui possèdent une même définition de service et de PHB. [10]

18

Dans un domaine, on distingue les noeuds internes et les noeuds frontières : les premiers ce sont des équipements centraux du réseau qui appliquent le comportement approprié (PHB) aux paquets IP et assure le service de transit sur le réseau, alors que, les seconds ce sont des équipements de bordure de domaine DiffServ et qui sont connectés à des noeuds de frontières d'autres domaines.

Si on considère le sens de communication de la source vers la destination, les noeuds de frontières peuvent être d'entrée dans le domaine ou de sortie.

? Région DiffServ (DS région)

C'est un ensemble contigu de domaines DiffServ, qui peuvent offrir la différenciation des services sur des routes empruntant ces domaines.

Chaque domaine ne met pas obligatoirement en oeuvre la même politique d'approvisionnement ni les même PHB. L'opérateur doit garantir que l'ensemble des domaines DiffServ assurera une QoS de bout en bout. [10]

Les routeurs du coeur de réseau réalisent des opérations simples de bufférisassions et de routage des paquets en se basant uniquement sur le marquage effectué par les routeurs situés en bordure de domaine DiffServ.

La différenciation de service se fait au niveau des deux mécanismes cruciaux du modèle DiffServ: l'ordonnancement et prévention de congestion.

Chaque sortie du routeur possède un nombre fixe de files logiques où le routeur dépose les paquets arrivant selon leur classe de service.

Les files sont servies en accord avec l'algorithme d'ordonnancement. Les trois fonctions principales de routeur de coeur de réseau sont: Routage, prévention de congestion, Ordonnancement, il n'est pas nécessaire pour DiffServ d'associer un régulateur de type Token Bucket à chaque file des routeurs de coeur de réseau. En effet, tous les trafics entrant dans le coeur de réseau ont déjà subi la fonction de police dans les routeurs de bordure. [7]

1.6.3. CLASSIFICATION DES SERVICES DIFFSERV

Les opérations de classification, contrôle et marquage, sont effectuées par les routeurs de bordure tandis que les routeurs centraux traitent les paquets en fonction de la classe codée dans l'en-tête IP selon un comportement spécifique: le PHB (Per Hop Behavior). [11]

Actuellement, il existe trois types de PHB :

19

o Expedited Forwarding (EF) : ce PHB permet de fournir une bande passante garantie avec un taux de perte, de délai et gigue faible.

Pour assurer l'efficacité du système, ce service devrait être réservé pour un certain type d'applications (critiques, multimédia, temps réel). La valeur recommandée pour le code DSCP EF PHB est « 101110 ». [6]

o Assured Forwarding (AF) : ce PHB permet de garantir une haute probabilité d'acheminement des paquets IP.

Quatre classes (AF1, AF2, AF3, et AF4) ont été ainsi définies avec des différents niveaux de traitement (rejet) en cas de congestion du réseau et trois niveaux de priorité y sont définis.

o Best Effort (BE) : service de l'internet par défaut c'est-à-dire sans qualité.

Nous résumons dans le tableau ci-dessous les différentes classes services selon leur priorité, puis dans la figure 1.7. Nous donnons des exemples d'applications courantes en leur associant les classes de services de l'architecture DIFFSERV :

Tableau 1. 2.Récapitulatif des priorités de service DiffServ

Classe de Service Priorité

Best Effort		Faible	Assured Forwading
Moyenne		Expedited Forwading
Forte

20

Figure 1. 7. Qualité de service requise pour les applications

1.6.3. LES DIFFERENTES METHODES DE GESTION DE LA QOS ? Le Surdimensionnement des réseaux

L'une des méthodes simples pour garantir de la QoS dans un réseau est de sur-dimensionner son réseau. Dans ce cas, la bande passante peut être considérée comme quasiment illimitée. [12]

Dans la réalité, un réseau dit surdimensionné offre environ une capacité 10 fois supérieure au trafic qu'il doit écouler. Cette surcapacité permet également de garantir un taux de perte quasi nul puisque le réseau est à même d'acheminer tout type de trafic.

? Modélisation et multiplexage statistique

La deuxième méthode la plus en vogue et la plus utilisée consiste à modéliser la superposition des flux afin de déterminer le dimensionnement des files d'attentes et des paramètres de police à configurer dans les équipements. [12]

Connue sous le vocable de multiplexage statistique, cette méthode est basée sur le constat qu'il est possible de déterminer par un modèle mathématique l'enveloppe de trafic résultant de la superposition de n flux.

Certes, il est nécessaire de pouvoir dimensionner un réseau et un équipement, mais cela doit rester dans des proportions raisonnables en termes d'implémentation.

1.7. NOTION D'EN-TETE IP

21

1.7.3. LE PROTOCOLE IP

Le protocole IP est un protocole qui fonctionne sur la couche réseau du modèle OSI ou internet du modèle TCP/IP, il représente le protocole réseau le plus répandu.

Il permet de découper l'information à transmettre en paquets, de les adresser, de les transporter indépendamment les uns des autres et de recomposer le message initial à l'arrivée [13]. Ce protocole utilise ainsi une technique dite de commutation de paquets.

1.7.3.1.1. STRUCTURE DE L'EN-TETE

Figure 1. 8. La structure de l'entête IP

1.7.3.1.2. DEFINITION DE DIFFERENTS CHAMPS

V' Le champ Vers

Le champ version est codé sur 4 bits. Il représente le numéro de version du protocole IP, il permet aux piles IP réceptionnant la trame de vérifier le format et d'interpréter correctement la suite du paquet.

V' Le champ IHL

Ce champ est codé sur 4 bits et représente la longueur en mots de 32 bits de l'entête

IP.

V' Le champ service

22

Le champ service "Type Of Service" est codé sur 8 bits, il permet la gestion d'une qualité de service traitée directement en couche 3 du modèle OSI.

Figure 1. 9. Le détail du champ TOS

? Description

o Le champ priorité

Le champ Priorité est codé sur 3 bits, il indique la priorité que possède un paquet. Voici les correspondances des différentes combinaisons :

Tableau 1. 3. Les correspondances des différentes combinaisons de priorité

Numéro Bits Description

0	000		Priorité basse	1
001	Prioritaire		2
010	Immédiat		3
011	Urgent		4
100	Très urgent		5
101	Critique		6
110	Supervision interconnexion		7
111	Supervision réseau

o Le champ délai

Le champ Délai "Delay" est codé sur 1 bit. Il indique la valeur du délai d'acheminement du paquet. Voici les correspondances des différentes combinaisons :

23

> 0 - Normal > 1 - Bas

o Le champ débit

Le champ Débit est codé sur 1 bit. Il indique la valeur du débit acheminé. Voici les correspondances des différentes combinaisons :

> 0 - Normal > 1 - Haut

o Le champ fiabilité

Le champ Fiabilité "Reliability" est codé sur 1 bit. Il indique la valeur de la qualité du paquet. Voici les correspondances des différentes combinaisons :

> 0 - Normal > 1 - Haute

o Le champ cout

Le champ Coût "Cost" est codé sur 1 bit. Il indique le coût du paquet. Voici les correspondances des différentes combinaisons :

> 0 - Normal > 1 - Faible

o Le champ MBZ

Le champ MBZ "Must Be Zero" est codé sur 1 bit. Comme son nom l'indique, il doit être mis à 0.

V' Le champ longueur totale

Le champ Longueur totale est codé sur 16 bits et représente la longueur du paquet incluant l'entête IP et les Data associées. La longueur totale est exprimée en octets, ceci permettant de spécifier une taille maximale de 2^16 = 65535 octets.

V' Le champ identification

Le champ Identification est codé sur 16 bits et constitue l'identification utilisée pour reconstituer les différents fragments. Chaque fragment possède le même numéro d'identification, les entêtes IP des fragments sont identiques à l'exception des champs Longueur totale, Checksum et Position fragment.

V' Le champ flags

24

Le champ Flags est codé sur 3 bits et indique l'état de la fragmentation.

V' Le champ position fragment

Le champ Position fragment est codé sur 13 bits et indique la position du fragment par rapport à la première trame. Le premier fragment possède donc le champ Position fragment à 0.

V' Le champ TTL

Le champ TTL (Time To Live) est codé sur 8 bits et indique la durée de vie maximale du paquet. Il représente la durée de vie en seconde du paquet. Si le TTL arrive à 0, alors l'équipement qui possède le paquet, le détruira.

V' Le champ protocole

Le champ Protocole est codé sur 8 bits et représente le type de Data qui se trouve derrière l'entête IP.

V' Le champ Checksum

Le champ Checksum est codé sur 16 bits et représente la validité du paquet de la couche 3. V' Le champ IP source adresse

Le champ IP source est codé sur 32 bits et représente l'adresse IP source ou de réponse. Il est codé sur 4 octets qui forment l'adresse A.B.C.D.

V' Le champ IP destination adresse

Le champ IP destination est codé sur 32 bits et représente l'adresse IP destination. Il est codé sur 4 octets qui forment l'adresse A.B.C.D.

1.7.3.1.3. DIFFERENCE ENTRE ENTETE IPV4 ET IPV6

25

Figure 1. 10. Entête IP

Figure 1. 11. Changement de l'entête TOS d'IPV4 vers COS en IPV6

26

CHAPITRE 2 : ETAT DE FONCTIONNEMENT DU RESEAU DE LA
GECAMINES

2.1. INTRODUCTION

Ce présent chapitre fera l'objet d'un bref aperçu sur la présentation de la Gécamines, en faisant une présentation des différents services utilisés dans le réseau actuellement pour révéler les besoins que présente l'entreprise en termes de qualité de service et enfin proposer une piste qui permettra à l'entreprise de satisfaire ses utilisateurs.

On se base sur la méthodologie Network Calculus, dans cette partie du travail nous allons présenter la phase 1 de notre méthodologie qui consiste à analyser le réseau existant en se basant sur les points suivants :

y' Analyse de la QOS dans le réseau local de Lubumbashi et celui de Kolwezi y' Identification des besoins des utilisateurs

y' Présentation des points forts et faibles du réseau

2.2. PRESENTATION GENERALE DE L'ENTREPRISE

La Gécamines est une entreprise publique à caractères industriel et commerciale, elle jouit d'une personnalité juridique et est soumise à la tutelle du ministère de mines.

Vu l'abondance des étapes historiques de cette entreprise depuis sa création jusqu'à nos jours, nous ne ferons qu'un survol de son histoire dans le cadre de notre travail.

Au XVIème siècle déjà, l'industrie du cuivre était très active et florissante, le cuivre du Katanga avait même l'objet d'un échange international et intercontinental car d'importantes quantité de ce métal provenant du Katanga se retrouvaient à l'ouest de la côte de l'océan indien à l'Est, et de là il était exporté en Europe.

C'est avec les accords de la conférence de Berlin qui octroyèrent au roi Léopold II de la Belgique l'Etat indépendant du Congo que ce dernier devait être mis en valeur ; ainsi, beaucoup d'investisseurs se sont intéressés et y ont participés par l'apport des capitaux privés. D'où la création le 15 avril 1891 de la compagnie du Katanga par l'exploitation du sol et du sous-sol du Katanga.

Après une seule expédition en 1892, JULES CORNET eut le génie de concevoir les grands traits géologiques du Katanga. Il signala plusieurs gisements importants de cuivre.

27

Pour résoudre certains problèmes fonciers, l'état indépendant du Congo avec la compagnie du Katanga signèrent des accords pour la concession d'un territoire en vue de l'exploitation minière. Un comité de gestion vue le jour le 19 juin 1900 : il était nommé comité spécial du Katanga. Celui-ci confia à la Tanganyika concession limitée (TCL) créée le 20 janvier 1899, la mission de faire des investigations en vue de l'exploitation minière du Katanga.

Ses travaux aboutirent le 18 novembre 1901 à la découverte de nombreux gisements de cuivre à Musonoi et Kolwezi. Ce qui a permis la création par le décret numéro 1473 signé par LEOPOLD II le dimanche 28 octobre 1906, d'une société dénommée UNION MINIERE DU HAUT KATANGA. Les actionnaires pour cette oeuvre furent l'EIC, le CSK, et la TCL.

Cette nouvelle entreprise avait l'exercice des droits miniers et des autres droits accessoires c'est-à-dire l'UMHK pouvait créer des établissements de commerces et d'industrie et effectuer toutes les opérations utiles à but social. Le siège de l'UMHK se trouvait au Congo tandis que son siège administratif était en Belgique.

Après son indépendance, le Congo devenu Zaïre signa deux ordonnances loi le 07 janvier 1966 : la première exigeait le transfert des sièges sociaux et administratifs des sociétés ayant leurs sièges d'exploitation au Zaïre. Seconde baptisée « Loi Bakija » résiliait toute les concessions et sessions accordées antérieurement à l'accession du pays à l'indépendance le 30 juin 1960, aux entreprises minières privées.

Suite au refus de l'UMHK de se palier aux exigences de ces deux ordonnances loi, le Zaïre repris ses droits et par une ordonnance présidentielle signée le 01 janvier 1967 attribua tous les biens meubles et immeubles appartenant à cette société et à ses filiales. Ce fut la fin de l'UMHK.

L'ordonnance loi numéro 67-01 signé le 02 janvier 1967 créa la GENERALE CONGOLAISE DES LINERAIS (GECOMIN en sigle) qui est devenue depuis le 14 septembre 1972 LA GENERALE DES CARRIERES ET DES MINES en abrégée GECAMINES.

Elle possède de représentations tant à l'intérieur qu'à l'extérieur du pays notamment à Likasi, Kolwezi, Bruxelles, Ndola etc. Toutes représentations sont à sa disposition pour avoir des informations en rapport avec la production, les conditions du marché, et avec la politique économique en générale.

28

Hormis ces représentations, la Gécamines s'étant sur une superficie d'environ 34 Kilomètre carrés dans le Haut-Katanga. Géographiquement la Gécamines comprend 3 zones (groupes) d'exploitation qui sont :

Groupe SUD

Comprenant les unités des usines de Lubumbashi, des laminoirs et câblerie et la mine de Kipushi.

Groupe CENTRE

Comprenant les usines de Shituru, siège de C.C.C et Minotéries de Kakontwe, les plantations de Mangombo, Kasonga et Kando.

Groupe OUEST

Comprenant les sièges localisés à Kolwezi (KTC, KZC, UZK, LUI, SKM etc.) et les Charbonnage de Luena.

2.3.OBJECTIFS DE LA GECAMINES

Les objectifs de la Gécamines se retrouvent à travers ses activités qui peuvent se résumer en trois points essentiels à savoir :

? La recherche et l'exploitation des gisements miniers,

? Le traitement des substances minérales provenant de ces gisements ? La commercialisation des produits après traitement des minerais.

La Gécamines est une entreprise publique à caractère industrielle et commerciale, elle jouit d'une personnalité juridique et est soumise à la tutelle du ministère de mines.

2.4.PRESENTATION DU DEPARTEMENT INFORMATIQUE

Vers les années 50, l'informatique à la GECAMINES était appelées MECANO qui dépendait de la Direction de Ressources Humaines (DRH) en abrégée et logeait dans le même bâtiment précité.

C'est avec l'indépendance et l'évolution de la technologie que l'actuel bâtiment DIF serait construit (il est à noter que ce fut de l'un de derniers bâtiments construit dans l'enceinte de la GECAMINES Lubumbashi).

29

C'est en ce moment-là que la GECAMINES va commencer à utiliser les ordinateurs à cartes perforée et par après l'utilisation des ordinateurs bandes magnétiques.

Aujourd'hui tout cela est remplacé par la miniaturisation (Cassettes et disques dur externes). Entre les sites de l'entreprise l'interconnexion se fait par faisceau et les agents de groupes pourraient travailler avec la centrale, considérée comme l'unité centrale située à Lubumbashi.

Il fallait aussi une antenne reliant chaque 50Km, malheureusement ces équipements sont tombés en pannes et cette difficulté est supprimée dans le système actuel par l'utilisation du satellite avec des antennes VSAT à Lubumbashi, Likasi et Kolwezi.

Le département informatique est subdivisé en trois divisions :

? RSS

Réseau sécurité système, une division qui se charge du déploiement et du maintien en condition opérationnelle de l'ensemble du système réseau et télécommunication de la GECAMINES. Elle se charge également de la conception du suivi et de l'observation des recommandations de l'audit de la politique de sécurité du système d'information de l'entreprise tant sur le plan logique que physique.

? UDP : Urbanisation, Développement et Projet

? SSU : Service Exploitation et Soutien aux Utilisateur

30

2.5.PRESENTATION DES DONNEES DU LAN DE LUBUMBASHI

2.5.1. PRESENTATION DE L'EXISTANT

Figure 2. 1. Aperçu de L'architecture réseau de Lubumbashi Source : DIF/RSS/Gestion de Réseau

Date : 17/09/2019

L'infrastructure de la Gécamines groupe SUD est l'une des rares entreprises locales qui puisse avoir une infrastructure réseau aussi grande qu'en termes des matériels et de sécurité. Les machines sont des serveurs dédiés de marque HP sur lesquelles tournent les systèmes d'exploitation serveur 2003 R2 et Windows server 2008 R2.

Cette liste présente les différents serveurs et leurs rôles respectifs :

o SRV DC 1 et 2 : ces sont des serveurs jouant le rôle de contrôleurs de domaine respectivement primaire et secondaire, de serveur DHCP et DNS interne. Ils permettent donc une attribution automatique des adresses IP aux ordinateurs comme (DHCP) et de faire une résolution des noms et adresses IP et s'occupant ainsi de la gestion de l'annuaire Active Directory de tout le réseau de la GECAMINES (DNS) ;

o SRV SQL 1 et 2 : ce sont des serveurs prenant en charge la base de données du réseau campus de la Gécamines ;

31

o SRV FTP 1 et 2 : sont des serveurs des fichiers permettant de stocker les fichiers de tous les utilisateurs de la Gécamines servant également les partage des imprimantes ;

o SRV BKP : ce serveur joue le rôle du serveur de backup au miroir, permettant de stocker les données du réseau et ainsi en faire un archivage. Notons que ce serveur a une capacité de stockage de 5 terra octets ;

o SRV APP 1 et 2 : servant de serveur d'application et permettant ainsi un partage des applications en réseau et on l'utilise comme un serveur d'accès VPN ;

o SRV DELTA : serveur des applications de paie ;

o EBS PROD : Serveur procédant les applications commerciales de la Gécamines ;

o EBS TEST : Copie d'EBS PROD ;

o SRV EXCHANGE 1 et 2 : serveur de messagerie avec exchange ;

o SRV TRIXBOX : serveur de la voix sur IP ;

o SRV CTX : serveur CITRIX pour la virtualisation des applications afin de remédier aux problèmes d'accès distant ;

o SRV SECU 1 : serveur jouant le rôle de pare-feu ;

o SRV WSUS : serveur de la mise à jour.

o SVR LYNC : serveur permettant la communication unifiée

NB : le réseau de la Gécamines est en perpétuels changement et est donc susceptible de subir les modifications dans les jours à venir.

2.5.2. COMPOSITION MATERIELLE ET ACCESSOIRES DIVERS Ce réseau contient plusieurs équipements en occurrence :

> Des VSAT ;

> Une antenne AIRMAX SECTOR ;

> Des antennes CPE POWER STATION ;

> Des antennes CPE NANO STATION ;

> Point d'accès de types CISCO Linksys, Dlinks, et Planet,

> Serveurs,

> Ordinateurs portables et fixes,

32

> Des IP-PHONES ;

> Scanners,

> Modems,

> Imprimantes ;

> Boites à fibre optique,

> Contrôleur des liaisons type MSL 6000,

> Câbles UTP,

> Câbles téléphoniques,

> Switch catalyst 2960 séries, Cisco 1600 séries,

> Onduleurs,

> Batteries sous un système de no-break

2.5.3. CALCULS DE LA VOLUMETRIE ET DU TEMPS DE

TRANSMISSION DANS LE LAN DE LUBUMBASHI

La bande passante est définie comme étant le taux de transfert des données sur un support de transmission, elle est mesurée en bits/sec [16].

La volumétrie d'un site est généralement issue d'une volumétrie unitaire estimée pour un utilisateur ; on peut utiliser la formule suivante :

VJ= Vu* u

Avec :

VJ : le volume journalier à calculer pour un site ;

Vu : le volume journalier estimé pour un utilisateur

u : est le nombre d'utilisateurs pour un site donné. [16]

La largeur de bande de la voix téléphonique est de 3100Hz, pour numériser ce signal correctement sans perte de qualité, il faut échantillonner à au moins deux fois la fréquence d'échantillonnage, ce qui nous donne 3100*2 = 6200 échantillons par seconde [17].

La normalisation UIT a opté pour un échantillonnage de 8000 fois par seconde ce qui nous donne 8Khz, comme nous savons que les octets qui sortent du codec (Codeur/Décodeur) donnent une première estimation sur la valeur du débit de la parole téléphonique, et ce débit

33

s'obtient en multipliant le nombre d'échantillons par le nombre d'échelons, ce qui nous donne :

Débit = 8000*8 = 64Kbps si le codage s'effectue sur 8bits, ce débit est estimé pour une seule conversation.

Vu que le LAN de Lubumbashi possède 29 utilisateurs pour la voix sur IP, nous aurons comme débit totale exigé :

Débit totale =64 * 29 = 1856 kbps pour 29 conversations

Considérant que les applications du type conversationnelles génèrent un trafic allant de 2 à 4 Ko par utilisateur et par jour [16].

Dans notre exemple nous allons prendre le trafic 4ko, ce qui nous donne les volumes journalier estimé pour un utilisateur pour le service de la voix sur IP suivant :

Vu pour la voix= 4Ko = 4*1024= 4096 Octets = 4096*8 = 32768 bits

Alors le volume journalier estimé pour le site de Lubumbashi est donné par : VJ voix = Vu*u= 32768*29 = 950272 bits

a) Calculs de la volumétrie pour la messagerie

Tout en sachant que l'entreprise dispose 1456 utilisateurs au total sur le service de messagerie avec exchange en locale (le LAN de Lubumbashi), avec un volume journalier estimé de 100ko (819200 bits) [16] pour un message par un utilisateur.

On peut calculer le volume journalier estimé pour le site de Lubumbashi en utilisant la formule suivante :

Vj messagerie = Vu * u = 819200 * 1456 = 1192755200 bits

b) Calcul de la volumétrie totale pour le service de la voix sur IP et le service de messagerie dans le site de Lubumbashi

La quantité totale de trafic généré (pour le flux de la voIP et la messagerie) est déterminée en additionnant les deux volumes journaliers estimés pour le site de Lubumbashi pour les deux services.

VJ total de L'shi = VJ voix + VJ messagerie = 950272+ 1192755200 = 1193705472 bits

34

c) Calculs du temps de transmission des flux multimédia entre les utilisateurs du réseau de Lubumbashi:

Dans cet intranet de Lubumbashi, le débit utilisé pour technologie Ethernet en interne est de 100Mbps et celui utilisé par les liaisons sans fils est de 56Mbps (entre les différents bâtiments de la Gécamines interconnectés par le Wi-Fi).

Pour déterminer le temps de transmission des flux multimédia entre les différents bâtiments du réseau, on divise la quantité des données sur le débit des liaisons sans fils dans l'intranet de Lubumbashi (56Mbps = 58720256 bits/sec).

????r=

VJ total de L'shi

??éb???? ????????????n

1193705472

= ???? ??é??

=

58720256

Pour déterminer le temps de transmission des flux multimédia entre les différents bureaux au sein d'un bâtiment, on divise la quantité des données sur le débit de la technologie Ethernet dans de LAN de Lubumbashi (100Mbps = 104857600 bits/sec).

????r=	VJ total de L'shi	=	1193705472	= ????, ???? ??é??
	??éb???? ????????rn????		104857600

NB : dans le cas de notre travail on ne s'intéresse pas à l'échange des flux multimédia dans l'intranet mais plutôt entre le réseau de Lubumbashi celui de Kolwezi

2.6. L'ARCHITECTURE RESEAU DE LA GECAMINES (LUBUMBASHI et KOLWEZI)

35

Figure 2. 2. Architecture du réseau de la Gécamines Source : DIF/RSS/Gestion de Réseau

Date : 17/09/2019

Cette architecture représente le réseau de la Gécamines ayant comme sites : Lubumbashi et Kolwezi ; ces sites sont interconnectés par le fournisseur d'accès à internet INTERSYS avec des liaisons sans fil ayant comme débit de liaison 2Mbps en Up Link et 3Mbps en Down Link. Pour atteindre le FAI (Fournisseur d'Accès à Internet) on utilise les faisceaux hertziens.

2.6.1. ANALYSE DE LA QUALITE DE SERVICE DANS LE LAN DE LUBUMBASHI ET DE KOLWEZI

Dans cette partie nous allons analyser le réseau face aux paramètres de la qualité de service tel que le temps de transmission des flux multimédia entre ces deux sites distant de la Gécamines. On sait bien que le volume total estimé pour le site de Lubumbashi est de : 1193705472 bits.

d) Calculs du temps de transmission des flux multimédia :

Pour déterminer le temps de transmission des flux multimédia vers le site distant, on divise la quantité des données sur le débit des liaisons sans fils offert par le fournisseur d'accès à internet (INTERSYS) en Up Link (2Mbps = 2097152 bits/sec).

36

Ttr =	VJ total de L'shi	1193705472 = 2097152 = 569, 20 séc soit 9, 4 minute
	débit liaison

2.6.1.1.CALCUL DE LA VOLUMETRIE DANS LE SITE DE KOLWEZI ET DU TEMPS DE TRANSMISSION

Le site de Kolwezi possède au total 400 utilisateurs clients sur le service de
messagerie avec exchange et 400 utilisateurs pour la voix sur IP en passant par Lync serveur.

a) Calculs de la volumétrie pour la voix sur IP

Vu pour la voix= 4Ko = 4*1024= 4096 Octets = 4096*8 = 32768 bits

VJ voix = Vu*u= 32768*400 = 13107200 bits

b) Calculs de la volumétrie pour la messagerie

Tout en sachant que la Gécamines Kolwezi dispose 400 utilisateurs clients sur le service de messagerie avec exchange en locale (le LAN de Kolwezi), avec un volume journalier estimé de 100ko (819200 bits) [16] pour un pour un message par utilisateur.

Vj messagerie = Vu * u = 819200 * 400 = 327680000 bits

VJT Kolwezi= VJ voix + VJ messagerie = 13107200 + 327680000 = 340787200 bits a) Calculs du temps de transmission des flux multimédia dans le site de Kolwezi:

Pour déterminer le temps de transmission des flux multimédia vers le site distant, on divise la quantité des données sur le débit des liaisons sans fils offert par le fournisseur d'accès à internet (INTERSYS) en Up Link (2Mbps = 2097152 bits/sec).

Ttr =	VJ total de L'shi	340787200 = _ 2097152 -- 162, 5 séc soit 2, 7 minutes
	débit liaison

2.6.2. IDENTIFICATION DES BESOINS DES UTILISATEURS 2.6.2.1.BESOINS FONCTIONNELS

Les besoins fonctionnels sont ceux qui décrivent les options du système à concevoir, en d'autres termes ceux qui sont directement liés au système. Pour répondre aux besoins ci-haut cités, nous proposons ce qui suit :

37

La configuration de la qualité de service dans le réseau de la Gécamines tout en définissant les niveaux de service, en régularisant la bande passante et en définissant la priorité pour les trafics sensibles au délai.

2.6.2.2. BESOINS NON FONCTIONNELS

Les besoins non fonctionnels sont ceux qui décrivent les options secondaires qui servent au bon fonctionnement du système, parmi ces besoins on peut citer :

? La disponibilité de service, ? La fiabilité,

? La trivialité,

? La performance du réseau.

2.6.3. PRESENTATION DES POINTS FAIBLES ET FORT DU RESEAU

2.6.3.1. POINTS FORT DU RESEAU

Parmi les points forts du réseau on peut citer :

? Un réseau disponible pour les services multimédias de divers formats tel que : la vidéosurveillance, la voix sur IP, la vidéoconférence, la messagerie avec exchange, les mails, les images etc.

? L'alimentation en permanence des matériels

? La disponibilité des services réseaux etc.

2.6.3.2. POINTS FAIBLE DU RESEAU

Tout oeuvre humaine ne manque jamais d'imperfection, de ce fait l'entreprise Gécamines n'a pas pu échapper à cette règle.

Les problèmes que présente ce réseau sont multiples mais notre curiosité s'est penchée sur la gestion des flux multimédias face à la qualité de service, raison pour laquelle nous avons l'obligation de l'innovation et amélioration, voilà la raison primordiale d'être de notre travail.

? Ce réseau pose un problème lié à la gestion des divers flux de trafics qui circulent en son sein entre les sites distants face à la qualité de service, il y'a pas de mécanisme de QoS dans le réseau car le routage des paquets IP est basé sur le service par défaut de l'internet (Best-Effort)

38

? La faible capacité de la bande passante,

? Manque de priorité pour les trafics sensible au délai.

2.6.3.3.PROPOSITION DE LA SOLUTION

Vu que le temps de transmission est très grand dans les deux sites de la Gécamines (Lubumbashi et Kolwezi), cela ne permet pas un bon fonctionnement des flux multimédia car on sous-entend une congestion dans le réseau.

Nous proposons une solution qui consiste à implémenter sur cette même infrastructure un modèle à intégration de service (INTSERV) qui va nous permettre de faire de la réservation des ressources (en terme de bande passante et de délai de transfert) pour chaque type de service pour fluidifier la circulation et optimiser la qualité de service en accordant la priorité au trafic sensible au temps tel que la voix sur IP.

39

CHAPITRE 3 : ANALYSE FONCTIONNELLE DU MODELE INTSERV

ET DIFFSERV

3.1. INTRODUCTION

Nous voici au troisième chapitre de notre travail, dans cette partie il sera question d'analyser des différentes fonctionnalités avancées du modèle DIFFSERV et INTSERV à l'aide des diagrammes UML selon les protocoles mis en oeuvre, la réalisation de qualité de service (classification, réservation etc.), les mécanismes fonctionnant au niveau du routeur puis nous ferons un choix sur le modèle à implémenter au sein du réseau de la Gécamines.

3.2. MODELE A DIFFERENCIATION DE SERVICE (DIFFSERV)

3.2.1. PRESENTATION ET PRINCIPE DE FONCTIONNEMENT

Le modèle DiffServ est un modèle de différentiation des services défini par l'IETF dans le RFC 2475, son objectif primordial est d'effectuent un traitement différencié des trafics (données, téléphonies IP, vidéo sur IP etc.), regroupés en quelques classes de services, pour garantir la qualité de service. [9]

Le principe de fonctionnement de DiffServ est la création de diverses classes de services fournissant chacune d'entre elles une qualité de service différente ; ces classes se distinguent les unes des autres par la présence d'un code dans le paquet IP : le DSCP (DiffServ Code Point).

Le marquage des paquets selon la qualité de service qu'il nécessite, se fait en périphérie du réseau, soit à la source directement ou soit au niveau du routeur de bordure et ensuite, les routeurs internes du réseau déterminent la priorité du paquet et le traitent en fonction de celle-ci.

Figure 3. 1. Schéma de principe du modèle DIFFSERV

3.2.2. PRESENTATION D'UN ROUTEUR DIFFSERV DE BORDURE

40

Figure 3. 2. Architecture d'un routeur DIFFSERV de bordure 3.2.3. LE DIAGRAMME DE CAS D'UTILISATION

+ Identification des acteurs

1. Acteur Principale : Routeur Emetteur

2. Acteur Secondaire : Routeur Récepteur

+ Identification des cas d'utilisations :

Avec le routeur de bordure du modèle Diffserv, nous avons retrouvés les quatre cas

d'utilisation suivants :

V' Cas d'utilisation 1 : Classifier paquets

V' Cas d'utilisation 2 : Conditionner l'envoi du trafic

V' Cas d'utilisation 3 : Gérer file d'attente

V' Cas d'utilisation 4 : Ordonnancer le trafic

41

Figure 3. 3. Diagramme de cas d'utilisation DIFFSERV

+ Description textuelle du diagramme de cas d'utilisation du modèle à service différenciés :

Vue le diagramme de cas d'utilisation de ce modèle, voici la description textuelle : V' Cas d'utilisation 1 : Classifier paquets

> Objectif du cas d'utilisation : la classification des paquets en fonction du type de service

> Acteur Principale : Routeur Emetteur

> Acteur Secondaire : Routeur Récepteur

> Précondition : le routeur émetteur doit être opérationnel et configuré avec le modèle à service différenciés (Diffserv)

> Scénario nominal : ce routeur sélectionne et classifie les paquets en se basant sur une partie de l'entête du paquet

42

> Scénario alternatif : impossibilité de classifier les paquets si le routeur émetteur est down et aussi si le modèle à service différencié n'est pas configuré sur le réseau

> Post-condition : paquet classifiés

V' Cas d'utilisation 2 : conditionner l'envoi du trafic

> Objectif du cas d'utilisation : adapter le trafic à certaines conditions requises pour l'envoi

> Acteur Principale : Routeur Emetteur > Acteur Secondaire : Routeur Récepteur

> Précondition : le routeur émetteur doit être opérationnel et configuré avec le

modèle à service différenciés (Diffserv)

> Scénario nominal : le trafic doit passer par les composants tels que la

métrologie, le marquage, le lissage ou le rejet des paquets

> Scénario alternatif : impossibilité de Conditionner le trafic si le routeur émetteur est down et aussi si le modèle à service différencié n'est pas

configuré sur le réseau

> Post-condition : trafic conditionné

V' Cas d'utilisation 3 : gérer file d'attente

> Objectif du cas d'utilisation : stocker les paquets selon leur priorités lorsque le

réseau est congestionné

> Acteur Principale : Routeur Emetteur

> Acteur Secondaire : Routeur Récepteur

> Précondition : le routeur émetteur doit être opérationnel et configuré avec le

modèle à service différenciés (Diffserv)

> Scénario nominal : utiliser un Algorithme de gestion de la file d'attente en cas

de congestion

> Scénario alternatif : difficulté de gérer la file d'attente si le modèle à service

différenciés n'est pas configuré

> Post-condition : la file d'attente gérée

43

V' Cas d'utilisation 4 : ordonnancer les paquets

> Objectif du cas d'utilisation : arbitrer la sortie des paquets prioritaires sur le

réseau

> Acteur Principale : Routeur Emetteur

> Acteur Secondaire : Routeur Récepteur

> Précondition : les paquets doivent être classifiés et les trafics doivent être

conditionnés

> Scénario nominal : autoriser en premier lieu les paquets prioritaires

> Scénario alternatif : difficulté d'ordonnancer le trafic non classifié et les

paquets non conditionnés

> Post-condition : paquets ordonnancés

3.2.4. DIAGRAMME D'ACTIVITE (DiffServ)

Ce diagramme n'est rien d'autre que la transcription dans UML de la représentation du processus tel qu'il a été élaboré lors du travail qui a préparé a préparé la modélisation, il montre l'enchainement des activités qui concourent au processus. [18]

Il nous permet de mettre l'accent sur le traitement ; il nous permet aussi de représenter graphiquement le déroulement des flux du trafic.

Figure 3. 4. Diagramme d'activités du modèle DIFFSERV

3.2.5. LES DIAGRAMMES DE SEQUENCE CLASSIFIER PAQUET

44

Figure 3. 5. Diagramme de séquence (Classifier paquets)

Figure 3. 6. Diagramme de séquence (Conditionnement du trafic)

NB : Chaque classe de service de qualité implique la création d'un contrat : le SLA (Services Level Agreement). Ce contrat précise des règles concernant le délai, la bande passante, le taux de disponibilité, la valeur du DSCP, la taille des tampons de la file d'attente pour cette classe dans les routeurs et le choix de la politique à utiliser en cas de non-respect du SLA (rejet des paquets, abaissement de la priorité du paquet etc.)

Par exemple si un SLS spécifie que l'application doit envoyer un trafic à 2 Mbit/s mais que le serveur émet un flux à 2,5 Mbit/s, le fournisseur est en droit de détruire le trafic excédent afin de protéger non seulement son réseau mais également les autres contrats pour lesquels il est engagé. C'est ça le niveau de conformité du trafic par rapport au SLA.

45

Figure 3. 7. Diagramme de séquence (Gérer file d'attente)

Figure 3. 8. Diagramme de séquence (Ordonnancer trafic)

NB : pour ce qui concerne les différentes valeurs de priorité, référez-vous dans le premier chapitre à la page 22.

46

3.3. LE MODELE INTSERV/RSVP

3.3.1. PRESENTATION ET PRINCIPE DE FONCTIONNEMENT

La première proposition d'architecture susceptible de prendre en charge la qualité de service (QoS) a été faite par l'IETF avec le modèle IIS (Internet Integrated Services) ou IntServ.

L'idée maitresse du modèle IntServ est de fournir une qualité de service individualisée à chaque connexion en utilisant un mécanisme de contrôle d'admission et de réservation de ressources via le protocole RSVP (Ressource reServation Protocol) dans les différents éléments du réseau.

Ce modèle a été définit dans le RFC 1633, il propose de réserver des ressources dans les noeuds du réseau avant de commencer à les utiliser ; Il se base sur le protocole RSVP permettant de faire de la réservation pour les flux de qualité de service (QoS). [11]

Un routeur IntServ/RSVP est composé de quatre fonctionnalités:

Le classificateur : il permet de classer chaque paquet entrant dans le routeur selon sa priorité.

L'ordonnanceur : il gère la sortie des paquets IP vers l'extérieur du routeur. Le contrôle d'admission : il décide lui, si la réservation d'un flux peut être acceptée en fonction de celles déjà existante sur le réseau.

Le processus de réservation RSVP : il permet quant à lui de créer et de mettre à jour les états concernant la réservation dans le routeur pour les chemins utilisant la qualité de service.

3.3.2. ARCHITECTURE D'UN ROUTEUR INTSERV/RSVP

47

Figure 3. 9. Architecture d'un routeur INTSERV

3.3.3. ANALYSE FONCTIONNELLE DU MODELE INTSERV/RSVP

3.3.3.1. DIAGRAMME DE CAS D'UTILISATION

+ Identification des acteurs

1. Acteur Principale : Routeur Emetteur

Il peut jouer le rôle d'un récepteur dans le cas où les utilisateurs du routeur faisant office d'un routeur secondaire envoient les paquets.

2. Acteur Secondaire : Routeur Récepteur

Il peut jouer le rôle d'un routeur émetteur au cas où les utilisateurs de ce routeur envoient les données ; c'est ce routeur qui impose le traitement de la qualité de service, si cette dernière n'est pas exécutée par le routeur émetteur.

+ Identification des cas d'utilisations :

V' Cas d'utilisation 1 : classifier paquets

V' Cas d'utilisation 2 : contrôler l'admission

V' Cas d'utilisation 3 : Ordonnancer paquets

V' Cas d'utilisation 4 : Réserver bande passante

V' Cas d'utilisation 5 : demander la qualité de service

V' Cas d'utilisation 6 : initialiser la réservation

V' Cas d'utilisation 7 : maintenir la réservation

48

Figure 3. 10. Diagramme de cas d'utilisation INTSERV

+ Description textuelle du diagramme de cas d'utilisation du modèle à service intégrés :

Vue le diagramme de cas d'utilisation de ce modèle, voici la description textuelle :

V' Cas d'utilisation 1 : classifier paquets

> Objectif du cas d'utilisation : la classification des différents trafics selon la

priorité.

> Acteur Principale : Routeur Emetteur

> Acteur Secondaire : Routeur Récepteur

> Scénario nominal : l'émetteur classe les paquets en fonction de leurs natures

> Post-condition : paquets classifiés

V' Cas d'utilisation 2 : contrôler l'admission

> Objectif du cas d'utilisation : autoriser les paquets à transiter sur le réseau

> Acteur Principale : l'émetteur

> Acteur Secondaire : le récepteur

49

> Scénario nominal : empêcher l'utilisateur d'envoyer les paquets tant que la classification ne soit finie

> Post-condition : paquets admis.

ü Cas d'utilisation 3 : ordonnancer paquets

> Objectif du cas d'utilisation : arbitrer la sortie des paquets prioritaires sur le réseau.

> Acteur Principale : Routeur Emetteur

> Acteur Secondaire : Routeur Récepteur

> Précondition : les paquets doivent être classifiés et l'admission doit être contrôlée.

> Scénario nominal : autoriser en premier lieu les paquets prioritaires tel que la voix sur IP

> Scénario alternatif : difficulté d'ordonnancer le trafic non classifié et les paquets dont on n'a pas fait le contrôle d'admission.

> Post-condition : paquets ordonnancés

ü Cas d'utilisation 4 : Réserver bande passante

> Objectif du cas d'utilisation : la réservation de la bande passante sur la liaison pour un trafic prioritaire

> Acteur Principale : l'émetteur

> Acteur Secondaire : le récepteur

> Précondition : contrôler l'admission, classifier les paquets et ordonnancer les paquets.

> Scénario nominal : réserver la bande passante pour le trafic prioritaire

> Post-condition : bande passante réservée.

ü Cas d'utilisation 5 : demander la qualité de service

> Objectif du cas d'utilisation : imposer le traitement de la qualité de service à l'émetteur

> Acteur Principale : le récepteur

> Acteur Secondaire : l'émetteur

50

> Précondition : s'authentifier

> Post-condition : qualité de service imposée.

y' Cas d'utilisation 6 : initialiser la réservation

> Objectif du cas d'utilisation : libérer la liaison pour une nouvelle demande de

la réservation de la bande passante.

> Acteur Principale : le récepteur

> Acteur Secondaire : l'émetteur

> Précondition : s'authentifier

> Scénario nominal : réserver une bande passante pour la voip

> Scénario alternatif :

> Post-condition : bande passante allouée.

y' Cas d'utilisation 7 : maintenir la réservation

> Objectif du cas d'utilisation : le maintien de la réservation permet d'éviter la

perte des paquets.

> Acteur Principale : le récepteur

> Acteur Secondaire : l'émetteur

> Précondition : s'authentifier

> Scénario nominal : réserver une bande passante pour la voip

> Post-condition : qualité de service imposée.

3.3.3.2. DIAGRAMME D'ACTIVITES INTSERV

Figure 3. 11. Diagramme d'activités du modèle INTSERV

51

3.3.3.3. LE PROCESSUS DE RESERVATION (RSVP) 3.3.3.3.1. PRESENTATION

Le protocole RSVP est un protocole de réservation des ressources défini dans le RFC 2205, il assure la signalisation pour allouer dynamiquement de la bande passante et garantir un délai pour des applications de l'internet. Ici, la demande de la qualité de service (QoS) ne se fait pas par la source mais par le récepteur. [11]

En effet, il apprend par un mécanisme hors bande les besoins de l'application. Cela lui permet de réaliser la réservation en fonction de ses besoins.

Les paquets RSVP sont encapsulés dans des paquets UDP et routés via des protocoles de routages classiques comme RIP, EIGRP, OSPF etc.

3.3.3.3.2. PRINCIPE DE FONCTIONNEMENT

Figure 3. 12. Fonctionnement du protocole RSVP

La source envoie un message PATH dans lequel elle donne les caractéristiques désirées dans un descripteur TSPEC, c'est-à-dire le débit, le délai et la taille du paquet. Ensuite, ce message PATH est acheminé de routeur en routeur jusqu'à la destination.

52

A chaque routeur, il y a création d'un état PATH-STATE qui permettra aux messages RESV d'être acheminés. A chaque routeur, les caractéristiques désirées par la source peuvent être modifiées selon les capacités des routeurs traversés.

Dès que la destination a reçu le message PATH, elle envoie un message RESV incluant les spécifications de la QoS demandée. Ce message RESV est à son tour acheminé jusqu'à la source.

A la réception du RESV, le dernier routeur avant la source génère un message RESV-CONF qu'il envoie à la destination. Cet échange de messages permet de faire la réservation RSVP entre la source et la destination.

3.3.3.3.3. DIAGRAMME DE SEQUENCE DE RESERVATION (RSVP)

Figure 3. 13. Diagramme de séquence (Fonctionnement RSVP) 3.3.3.3.4. LE PROCESSUS DE ROUTAGE

53

Comme nous l'avons annoncé ci-haut, les paquets RSVP sont encapsulés dans des paquets UDP et routés via des protocoles de routages classiques comme RIP, EIGRP, OSPF etc.

Figure 3.15. Diagramme de séquence (Processus de routage RSVP)

Figure 3.16. Diagramme de séquence (Evaluation du service et réservation)

3.1.1.1.1. DIAGRAMME DE SEQUENCE EVALUATION DE SERVICE ET RESERVATION DE LA BANDE PASSANTE

54

3.1.1.1.2. CONCLUSION PARTIELLE

Ce chapitre nous a permis de faire une analyse fonctionnelle de deux modèles à qualité de service (INTSERV et DIFFSERV) à l'aide des diagrammes des cas d'utilisations, les diagrammes de séquences ainsi que les diagrammes d'activités.

Apres cette analyse nous avons retenus le modèle à intégration des services (INTSERV) comme celui pouvant assurer la qualité de service dans notre réseau de la Gécamines (Site de Lubumbashi et Kolwezi) en utilisant l'algorithme LLQ pour l'ordonnancement, nous allons configurer la classification des paquets, le contrôle d'admission, l'algorithme LLQ ainsi que le protocole RSVP qui sont les étapes du modèle INTSERV.

55

CHAPITRE 4 : OPTIMISATION DE LA QUALITE DE SERVICE DANS LE RESEAU DE LA GECAMINES

4.1. INTRODUCTION

Nous voici au dernier chapitre de notre travail, après avoir effectué la première phase de notre méthodologie dans le deuxième chapitre où nous avons parlé de l'état de fonctionnement du réseau de la Gécamines, nous avons évalué ce réseau par rapport à la qualité de service et cela nous a permis de connaitre le temps de transmission des flux multimédia entre le sites distants qui est de 9,4minutes pour le site de Lubumbashi et 2,7 minutes pour le site de Kolwezi.

Dans ce chapitre nous allons passer à la phase 2 de notre méthodologie qui consistait à proposer quelques pistes de solution pour l'optimisation de la qualité de service au sein de ce réseau afin de lutter contre la congestion, puis nous allons passer à la présentation de notre maquette de configuration du modèle à intégration de service (IntServ).

4.2. OPTIMISATION DE LA QUALITE DE SERVICE

L'optimisation d'un réseau consiste à améliorer les performances du réseau en termes de la qualité de service (QoS) ; pour optimiser un réseau on intéresser aux paramètres suivants : le débit, le délai et la charge [1]. Dans notre travail nous allons surtout nous baser sur le débit des liaisons sans fils offert par le fournisseur d'accès à internet (INTERSYS) pour la liaison Lubumbashi et Kolwezi et la proposition du modèle INTSERV.

4.2.1. PROPOSITION DES PISTES DE SOLUTION

Vu que le temps de réponse calculé dans les deux sites est trop grand, cela ne permet pas le bon fonctionnement des flux multimédia dans le réseau de la Gécamines surtout pour le trafic sensible au délai tel que la voix, nous proposons les solutions suivantes à l'entreprise :

y' Le modèle à intégration de service (IntServ) est une solution permettant le traitement différencié des trafics sur ce réseau en réservant la bande passante pour les applications à très forte contraintes temporelle en utilisant le protocole RSVP ;

y' Le dimensionnement des liaisons sans fil vers le F.A.I pour calculer la bande passante nécessaire afin de calculer le temps de réponse acceptable pour quitter d'un site vers un autre.

56

Figure 4. 1. Architecture réseau

4.2.1.1. CALCULS DE LA BANDE PASSANTE

Pour dimensionner une liaison, il convient d'estimer les besoins en termes de la bande passante [16]. La formule de calcul généralement admise est la suivante :

1 1

Bp = Vj× Th × Ov × Tu X × (8 × 1024)

3600

? Bp : est la bande passante instantanée calculée pour une liaison

? Vj : est le volume journalier, estimé pour un site en bits. Cette valeur représente la somme des flux devant circuler sur le lien considéré.

? Th : est un coefficient permettant de calculer le trafic ramené à l'heure chargée. On considère généralement que le trafic journalier est concentré sur une heure chargée. Cette hypothèse part du constat que, sur 8 heures de travail, les utilisateurs sont très actifs sur deux périodes de pointe, entre 10 h et 11 h, et entre 15 h et 16 h. Les valeurs généralement admises sont comprises entre 20 % et 30 % du trafic journalier concentré sur une heure.

? Ov : est l'overhead généré par les protocoles de transport (TCP, IP, PPP). Ce coefficient est généralement affecté d'une valeur de 20 %. Il tient compte des en-têtes et des paquets de service (acquittements, etc.).

? Tu : est le taux maximal d'utilisation de la bande passante du lien. Cette correction permet de prendre en compte le fait que l'on utilise rarement 100 % du débit nominal

57

d'un lien. Ce taux est généralement fixé à 80 % de la bande passante. Pour des liaisons à haut débit, ce taux peut atteindre 90 %.

Dans notre travail cette bande passante se calculs avec la formule suivante :

??

BP = ???? (??'??h?? o?? ??'????)x Th X Ov X ?? ? ??? X X (8X1024)

??6????

? Calculs de la bande passante et du temps de transmission dans le site de Lubumbashi:

BP = 1193705472x 0,30 x 0.20x

= 89527910,4 bit/s soit 85,38Mbps

??6????

1

X

0,8

??

??I (??'??h?? ) ?????? = ????

1193705472 = 89527910,4

= ????,???? ??é??

? Calculs de la bande passante et du temps de transmission dans le site de Kolwezi:

1 ??

BP = 340787200x 0,30 x 0.20x X = 25559040 bit/s soit 24,37Mbps

0,8 ??6????

??????=

???? (??'????) ????

340787200 = 25559040

= ????, ???? ??é??

Proposition du tableau contenant des exigences en métriques de qualité de service des flux multimédia :

Tableau 4. 1. Exigences en métriques de qualité de service des flux multimédia

Flux multimédia Délai de bout en bout				Gigue tolérée			Bande passante
Flux de voix sur IP	< 300 ms		< 20 ms			De 64 kbps à 128 kbps
Flux de vidéo IP	< 400 ms		< 20 ms			De 40 à 384kbps
Images fixes	Pas de contrainte temporelle		Supporte des variations de délai			Pas fixée
Flux des données	Pas de contrainte temporelle		Supporte des variations de délai			Pas fixée

Source : Thèse de doctorat: Architecture de communication multimédia et multi-réseaux, par Pascal Berthou, Institut National Polytechnique de Toulouse, 2001

58

4.3. CREATION DE LA MAQUETTE

4.3.1. PLAN DE CONFIGURATION

Notre maquette de configuration contiendra deux service (le service de la Voix sur IP et celui de données) sur GNS3, c'est sur ce réseau que nous allons configurer le modèle à intégration des services (INTSERV) comme nous l'avons souligné dans notre troisième chapitre après les analyses fonctionnelles.

Par défaut le réseau est conçu pour véhiculer les données, raison pour laquelle nous allons procédés à la configuration de la voix sur IP sur le même support de transmission que les données. Ayant constaté que GNS3 ne comporte pas des téléphones IP, nous avons utilisé un logiciel nommé Cisco IP COMMUNICATOR qui représente le téléphone IP.

4.3.2. L'ENVIRONNEMENT MATERIELS ET LOGICIELS

Les matériels et logiciels qui nous permettent d'implémenter cette solution sont : Tableau 4. 2. L'environnement matériels et logiciels

Outils Nombre Caractéristiques

Un ordinateur (Laptop)	1	Windows10, Intel® Core duo, i5-3427U CPU@ 2.30 Ghz du processeur ; RAM 4 Go, 300 Go de disque dur, 64bits.
Une machine virtuelle	1	Windows7 Professionnelle, 1Go de RAM et 20 Go de disque dur
Un émulateur GNS3	1	Version 1.3
Routeur Cisco 7200	2	512Mbit de RAM et 512Mbits de NVRAM, des ports sériels et FastEthernet
Switch	2	128Mbit de RAM et 256Mbit de NVRAM
VMware-workstation	1	Version 12.1.0
Cisco IP Communicator	2	Version 8.6.6.1

4.3.3. ARCHITECTURE RESEAU

59

Figure 4. 2. Architecture réseau de la maquette Source : Capture d'écran

Cette architecture réseau représente d'un côté le LAN de Lubumbashi et de l'autre côté le LAN de Kolwezi, dans chaque site on a une machine sur laquelle on a installé le logiciel Cisco IP COMMUNICATOR qui représente le téléphone IP.

4.3.4. PLAN D'ADRESSAGE Tableau 4. 3. Plan d'adressage

Réseau @ Réseau Interface @ Interface

LAN1	192.168.100.0/24 Pour la Voix 172.16.0.0/24 Pour les Données 10.0.0.0/24 Pour la Liaison Série	FastEthernet 0/0.1	192.168.100.1
		FastEthernet 0/0.2	172.16.0.1
		Serial 1/0	10.0.0.1
LAN2	192.168.200.0/24 Pour la Voix 172.16.1.0/24 Pour les Données 10.0.0.0/24 Pour la Liaison Série	FastEthernet 0/0.1	192.168.200.1
		FastEthernet 0/0.2	172.16.1.1
		Serial 1/0	10.0.0.2

60

Nous avons configuré l'attribution automatique de ces adresses à l'aide du protocole DHCP en créant le pool Voice pour la voix et Data pour les données dans chaque LAN.

Nous utilisons le logiciel Cisco IP COMMUNICATOR que nous avons connecté à la machine virtuelle et à la machine physique de bout en bout dans notre architecture réseau de la maquette. Ce logiciel doit être configuré en suivant différentes étapes, les téléphones qui communiquent sur le réseau doivent être reconnu par ce dernier, c'est pourquoi nous devons configurer les numéros de téléphone qui doivent communiquer à travers nos deux routeurs.

V' Configuration des numéros de téléphone sur le premier routeur

dial-peer voice 1 voip

destination-pattern 0858524432

session target ipv4:10.0.0.2

V' Configuration des numéros de téléphone sur le deuxième routeur

dial-peer voice 1 voip

destination-pattern 0976900906

session target ipv4:10.0.0.1

Apres avoir configuré les numéros téléphoniques, nous devons de même fixer un

nombre maximum des utilisateurs pour empêcher à ce que les téléphones non reconnus ne

puissent pas communiquer à travers le réseau.

V' Sur le premier routeur

telephony-service

no auto-reg-ephone

max-ephones 10

max-dn 20

ip source-address 192.168.100.1 port 2000 strict-match

timeouts ringing 10

system message CCNA VOICE By Delly MPUNGU

V' Sur le deuxième routeur

61

telephony-service

no auto-reg-ephone

max-ephones 10

max-dn 20

ip source-address 192.168.200.1 port 2000 strict-match

timeouts ringing 10

system message CCNA VOICE By Delly MPUNGU

Nous devons configurer l'adresse MAC pour que le logiciel Cisco IP COMMUNICATOR soit reconnu physiquement sur le réseau.

V' Sur le premier routeur

ephone 1

mac-address 000C.2952.E581

type CIPC

button 1:1

V' Sur le deuxième routeur

ephone 1

mac-address 0050.56C0.0008

type CIPC

button 1:1

4.3.5. CONFIGURATION DE LA CLASSIFICATION DES FLUX

Pour classifier les flux avec le modèle IntServ (integrated service), nous devons au préalablement créer les listes de contrôle d'accès (ACL) sur nos routeurs, ce qui nous a permis de grouper les flux selon leur types.

V' Configuration des ACL sur le premier routeur

62

ip access-list extended VOIP

permit udp 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 dscp ef ip access-list extended data

deny udp 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 dscp ef permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 dscp af31 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 dscp af43 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255 dscp default

V' Configuration des ACL sur le deuxième routeur

ip access-list extended DATA

deny udp 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255 dscp ef permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255 dscp af31 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255 dscp af43 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255 dscp default ip access-list extended VOIP

permit udp 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255 dscp ef

Apres que nous ayons créés les ACL, nous allons procéder à la classification des flux à partir de ces derniers.

V' Configuration de la classification des flux sur le routeur 1

class-map match-all voip

match dscp ef

match access-group name voip

class-map match-all data

match dscp default af31 af43

match access-group name data

V' Configuration de la classification des flux sur le routeur 2

63

class-map match-all voip

match dscp ef

match access-group name voip class-map match-all data

match dscp default af31 af43 match access-group name data

4.3.6. CONFIGURATION DE L'ALGORITHME D'ORDONNANCEMENT

LLQ

Nous allons configurer l'algorithme LLQ sur nos deux routeurs, une façon pour nous de prioriser les trafics sensibles au délai ; tel est l'exemple du service de la voix sur IP dans le cas de notre réseau.

V' Configuration de l'algorithme LLQ sur le premier routeur

policy-map LLQ

class data

set dscp af43

bandwidth percent 30

class voip

set dscp ef

priority percent 45

V' Configuration de l'algorithme LLQ sur le deuxième routeur

policy-map LLQ

class data

set dscp af43

bandwidth percent 30

class voip

set dscp ef

priority percent 45

64

4.3.7. CONFIGURATION DU PROTOCOLE RSVP

Nous allons configurer le protocole RSVP qui va faire de la réservation de la bande passante de 128Kbit/sec dans la limite de 64Kbit/sec pour la voix sur IP.

V' Configuration de RSVP sur le premier routeur Ip rsvp bandwidth 128 64

V' Configuration de RSVP sur le deuxième routeur Ip rsvp bandwidth 128 64

65

CONCLUSION GENERALE

Certes, nous voici au terme de notre travail de fin d'études dont le sujet s'intitule : « Problématique de gestion d'un réseau multiservices et son impact sur la QOS » cas de la Gécamines Lubumbashi et Kolwezi.

Dans ce travail il était question d'analyser le réseau de la Gécamines face à la QOS vu que ce réseau transmet un nombre accru d'applications multimédia de divers format tel que les images, images animées, la voix sur IP, les emails etc. et ces différents services partagent une même bande passante disponible ; cela entrainent de congestion de réseau qui se traduit par un ralentissement de temps de réponse.

Vu ces facteurs, notre problématique a tourné autour de ces deux questions à savoir :

? Quelle démarche scientifique pouvons-nous adopter pour fluidifier facilement le trafic afin d'éliminer la congestion dans le réseau de la Gécamines ?

? Comment pouvons-nous optimiser la QoS dans un réseau à flux multimédias ?

A travers ces questions nous nous sommes fixés un objectif principal de diminuer le temps de transmission des flux multimédia entre les deux sites de la Gécamines pour éliminer la congestion dans ce réseau. Pour cela, nous avons :

? Evaluer la qualité de service dans les deux sites de la Gécamines (le LAN de Lubumbashi et celui de Kolwezi) en calculant le temps de réponse du système pour les flux multimédias échangés ;

? Etudier les modèles de la qualité de service dans le réseau tel que le modèle à intégration de service (IntServ) et le modèle à différentiation des services (DiffServ) à l'aide de l'outil UML.

? Choisir un modèle qui nous permettra d'optimiser la qualité de service (QoS) dans le réseau de la Gécamines.

Pour atteindre cet objectif principal nous avons utilisés la démarche Network Calculus qui permet de calculer les bornes sur le délai et la bande passante en analysant le comportement du réseau de bout en bout.

Cette démarche nous a permis d'évaluer les performances du réseau de la Gécamines en déterminant le temps de transmission des flux multimédia. Dans ce travail nous avons diminué ce temps de réponse du système à 13,33 Sec en dimensionnant la bande passante des liaisons sans fils du fournisseur d'accès à internet.

66

Nous avons choisi le modèle IntServ que nous avons proposé à la Gécamines pour l'optimisation de la QoS en se basant sur une réservation des ressources (bande passante et un délai d'acheminement) pour le flux à forte contrainte temporelle à l'aide du protocole RSVP.

En fin, nous avons procédé à la présentation de notre maquette de configuration du modèle à intégration des services (IntServ) qui s'est fait dans quatre étapes à savoir :

1. La configuration de la classification des paquets qui se fait à travers les Access List qui sont configurés de manière à interdire le trafic de la voix sur IP à se mêler dans les trafics de données et vice versa ;

2. Le contrôle d'admission qui est configuré de manière à admettre les paquets qui doivent transiter sur le réseau en respectant la qualité de service ;

3. L'ordonnancement de paquets qui se fait à travers l'algorithme LLQ (Low Latency Queuing) qui permet de prioriser le trafic sensible au temps tel que la voix sur IP ;

4. La réservation des ressources avec le protocole RSVP qui nous a permis de réserver les ressources réseaux pour les flux à fortes contraintes temporelles tel que la voix sur IP.

Nous pensons avoir proposé une solution qui va tant soit peu améliorer la QoS dans le réseau de la Gécamines, nous ne prétendons pas avoir exploité toutes les possibilités pour résoudre ce problème de la QoS, nous laissons ici une brèche pour ceux qui voudrons bien marcher dans nos sillages pour proposer plus que nous.