Soutenance mémoire
Les enjeux de la gestion réseau
En quelques décennies, l’informatique a su s’imposer comme un élément indispensable pour le traitement et l’échange d’information. D’une part, cet outil permet d’effectuer de nombreux calculs en un temps beaucoup plus court que manuellement. D’autre part, et il s’agit là de la raison majeure du développement informatique, la capacité de faire communiquer des ordinateurs, c’est-à-dire de les mettre en réseau, a ouvert la voie à de nouvelles applications, des possibilités inédites, d’abord sur le plan militaire, puis économique, et enfin personnel. Ainsi, les parcs informatiques des entreprises n’ont cessé de croître, de manière exponentielle quelquefois. Les échanges commerciaux sont facilités, la communication au sein même de l’entreprise améliorée. Néanmoins, ce développement des infrastructures réseaux, en dépit de tous ses avantages, se heurte à un certain nombre de défis, d’importance parfois proportionnelle à sa taille. La diversité des équipements, leur complexité, ainsi que leur nombre sont autant de paramètres qu’un administrateur réseau doit prendre en compte pour une gestion efficace. Les défis auxquels l’ administrateur réseau doit faire face sont principalement: les pannes des équipements, les attaques contre le réseau, les manœuvres maladroites d’employés, mais aussi, plus fréquemment, la congestion de certains équipements.
Face à ces exigences, l’administrateur réseau doit travailler avec des contraintes opérationnelles. Les enjeux financiers peuvent en effet s’avérer substantiels. Par exemple, une panne de réseau bancaire, bloquant des transactions, pourrait coûter des milliers voire des millions de dollars à la banque et ses clients. Le droit à l’erreur est alors difficilement toléré. Plus généralement, la gestion de réseau peut se définir comme la mise en place de moyens qui assurent le service attendu par les utilisateurs, tout en gardant une certaine souplesse permettant 1′ évolution du réseau selon la vision de 1′ entreprise. L’administrateur réseau occupe donc un poste-clé dans l’entreprise, en étant garant d’un aspect crucial au bon fonctionnement de celle-ci.
Virtual Private Networks
Le principe d’un VPN est d’établir la connectivité entre différents sites d’un client en utilisant une infrastructure publique, tout en fournissant un contrôle d’accès et des politiques de sécurité semblables à un réseau privé [10]. Ce concept n’est donc en luimême aucunement lié à MPLS et était déjà mis en place avant son apparition. Ainsi, afin de mieux cerner l’ apport de MPLS dans le cadre de VPN, considérons d’abord son déploiement sans MPLS. Deux implémentations de VPN se sont très répandues: le modèle Overlay et le modèle Peer-to-Peer [10]. Le modèle Overlay est illustré à la figure 5 [18]. Ici, le fournisseur établit des lignes émulées entre les différents sites du VPN [10]. Le client peut alors établir des communications entre ses routeurs via ces circuits L’infrastructure du fournisseur d’accès est ainsi transparente au client, alors que le réseau interne de ce dernier reste caché au fournisseur. Typiquement, des technologies de niveau 2 sont mises en place pour le modèle Over/ay, comme ATM avec ses Permanent Virtual Connection (PVC) ou Switched Virtua/ Connection (SVC) [10]. Des technologies comme Generic Routing Encapsu/ation (GRE) [19] et IPSec [20] permettent aussi le déploiement du modèle Over/ay au niveau 3.
Traffic Engineering
Une autre grande application de MPLS est le traffic engineering, ou ingénierie de trafic. Pour bien comprendre son principe, on a coutume de présenter le fameux « problème du poisson ».
Pour remédier à ce problème, plusieurs options sont envisageables :
a. Modifier les métriques pour faire passer le trafic par R4 et R5 plutôt que R6 : mais on ne fait là que déplacer le problème;
b. Réajuster les métriques pour effectuer du load-sharing entre les routes R3-R6-R7 et R3-R4-R5-R6-R7 : si cette solution apparaît satisfaisante pour ce cas-ci, elle n’en reste pas moins difficile à mettre en place pour des topologies de réseau plus larges, et souffre donc d’un sérieux problème de mise à l’échelle;
c. Utiliser plusieurs chemins définis selon plusieurs critères, incluant la métrique, mais aussi la bande passante nécessaire, afin d’optimiser l’exploitation des ressources réseaux: c’est là que MPLS TE entre enjeu. La notion de TE n’est nullement restreinte à la technologie MPLS. Néanmoins, dans ce contexte, elle peut être puissamment déployée, en créant des LSP particuliers : on parle de tunnels. Il est alors possible de créer des tunnels garantissant une certaine bande passante, dont le chemin est calculé avec l’algorithme du Constraint Shortest Path First (CSPF) [15]. De cette façon, si un lien ne présente plus assez de bande passante disponible pour un trafic particulier, le Label Switched Path (LSP) s’établira en prenant une autre voie, peut-être moins directe, mais satisfaisant les conditions requises : des liens sous-utilisés seront ainsi rentabilisés.
En plus de seulement garantir de la bande passante, les tunnels MPLS TE offrent d’autres fonctionnalités offrant plus de flexibilité dans leurs déploiements. Par exemple, à un tunnel est affectée la notion de priorité, permettant à des tunnels jugés plus prioritaires de s’établir, même si cela doit se faire au détriment d’autres tunnels moins importants. En fait, deux priorités sont définies : la priorité d’établissement, prise en compte lorsque le tunnel cherche un chemin, et la priorité de maintien, utilisée une fois que le tunnel est mis en place. Une autre propriété de MPLS TE est l’affinité, laquelle consiste à marquer les liens et les tunnels, pour privilégier ou restreindre un chemin. Par exemple, si 1′ on souhaite établir un tunnel entre Montréal et Vancouver sans vouloir passer par les États-Unis, on marque alors les liens transfrontaliers d’une certaine valeur et le tunnel d’une autre. Ainsi, le tunnel restera au Canada.
Le contexte de MPLS : le paradigme des réseaux convergents
MPLS en tant que tel ne se limite pas à l’apport d’une technologie supplémentaire parmi tant d’autres, mais s’affiche comme un élément clé d’une mutation majeure des réseaux. En effet, l’observation de l’évolution du monde des télécommunications montre depuis quelques années une tendance très forte vers un nouveau paradigme de réseau. Ce profond changement s’est opéré du fait de plusieurs facteurs [22] :
a. La dérégulation des marchés, qui a permis une concurrence plus féroce entre les différents acteurs, poussant chacun à innover tout en réalisant des économies d’échelle pour rester compétitif;
b. L’apparition de nouveaux services proposés au consommateur: l’échange de voix seule ne suffit plus, de nombreuses fonctionnalités multimédia sont déployées, notamment l’accès à Internet à haut débit, quel que soit l’endroit où se trouve 1 ‘usager;
c. Les évolutions technologiques des réseaux de données de ces dernières décennies, notamment la prépondérance, pour ne pas dire hégémonie, de la technologie IP dans le monde, le développement de nouvelles technologies comme MPLS, lesquelles permettent de nouvelles fonctionnalités et l’évolution des réseaux de transport vers du très haut débit (commutation optique, multiplexage de longueur d’ondes, en anglais Wavelength Dense Multiplexing (WDM)). Ces différents éléments ont clairement fait ressortir à la fois le besoin et la possibilité technique d’une évolution des réseaux de télécommunications traditionnels, vers un réseau plus rapide, plus riche en fonctionnalités tout en étant plus économique.
Les nouvelles technologies ont notamment permis d’acheminer sur IP des informations avec des contraintes de QoS fortes, chose impossible avec IP seulement. Ainsi, les réseaux de voix et de données, jusqu’alors clairement distincts, ont convergé pour ne former qu’un seul et même réseau: on parle de réseau convergent. Toute l’information, voix ou données, transite sous forme de paquets sur des réseaux de données, majoritairement IP.
RFC
La démocratisation de MPLS s’est accompagnée de la publication d’un certain nombre de RFC pour gérer efficacement cette technologie. Ainsi, un .framework pour la gestion de MPLS a été établi, A Framework for MultiProtocol Label Switching (MP LS) Operations and Management (OAM) [25]. Cette RFC (4378) reprend les cinq points de la gestion réseau (FCAPS) tout en explicitant chacun dans le cadre de MPLS. Il permet ainsi une vue globale de la problématique abordée ici. Néanmoins ce document reste général : il tire les grandes lignes des défis à relever pour la gestion des réseaux MPLS, sans vraiment proposer de solutions. La RFC 4377 [9], OAM Requirements for MPLS Networks présente également les exigences en OAM de réseaux MPLS, collectées auprès de professionnels des réseaux ayant déployé et testé MPLS, notamment les fournisseurs de service. Cette RFC permet donc d’être sensibilisé aux besoins de gestion des réseaux MPLS, tout en tirant profit de l’ expérience du monde industriel.
Cependant, là encore, aucun élément de résolution n’est apporté, la RFC soulevant seulement les difficultés de l’OAM. Outre ces recommandations d’ordre général, plusieurs RFC abordent la problématique de la gestion de réseaux MPLS d’une manière plus spécifique. Ainsi, la RFC 4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures [26], aborde la problématique de détection et de localisation de défaillances dans un LSP. L’idée générale est de reprendre le paradigme pingltraceroute cher au monde IP, en l’ adaptant à MPLS. Ce document précise ainsi le format des paquets pinget traceroute MPLS tout en détaillant leur mode de fonctionnement. Par ailleurs, plusieurs recommandations abordent l’utilisation de SNMP pour MPLS, SNMP demeurant le protocole de gestion de réseaux le plus utilisé. Ainsi, la RFC 4221 Multiprotocol Label Switching (MP LS) Management Overview [27] présente les différentes Management Information Bases (MIB) proposées pour MPLS. Plutôt que d’avoir une seule MIB pour MPLS, une division a été opérée, permettant de regrouper les objets importants selon les différents aspects de MPLS, les divers éléments de son architecture ou ses applications. Par exemple, une MIB est dédiée pour les informations relatives à LDP, une autre pour le TE, une troisième pour le VPN. Les MIB MPLS sont détaillées dans des RFC particulières [28-31].
|
Table des matières
ABSTRACT
REMERCIEMENTS
LISTE DES TABLEAUX
LISTE DES FIGURES
LISTE DES ABRÉVIATIONS ET SIGLES
INTRODUCTION
CHAPITRE 1 PROBLÉMATIQUE
1.1 Les enjeux de la gestion réseau
1.2 Problématique du projet
1.3 Contexte du projet
CHAPITRE 2 ÉTAT DE L’ART ET BESOINS
2.1 Multi Protoco1 Label Switching
2.1.1 Terminologie
2.1.2 Présentation
2.1.3 Applications
2.1.3 .1 Virtual Private N etworks
2.1.3 .2 Traffic Engineering
2.1.4 Le contexte de MPLS : le paradigme des réseaux convergents
2.2 Approches et outils de gestion MPLS
2.2.1 RFC
2.2.2 Approches expérimentales
2.2.3 Outils industriels
2.2.4 Forces et faiblesses de ces outils
2.3 Des besoins non satisfaits
CHAPITRE 3 QMA : UN NOUVEL OUTIL
3.1 Spécifications proposées
3 .1.1 Exigences fonctionnelles
3.1.2 Exigences non fonctionnelles
3.2 Réponses aux exigences
3 .2.1 Interaction avec le réseau (spécifications 1 à 4, 14, 15)
3.2.1.1 Position du problème
3 .2.1.2 Différentes alternatives
3.2.1.3 ChoixdeSNMP
3.2.2 Méthode de détection des pannes (spécification 5)
3.2.2.1 Position du problème : insuffisance des mécanismes existants
3.2.2.2 Différentes alternatives
3.2.2.3 Méthode de détection proposée
3.2.3 Méthode de prévision de trafic (spécification 6)
3.2.3.1 Position du problème
3.2.3.2 Différentes alternatives
3.2.3.3 Choix d’une méthode: Holt-Winters
3.2.4 Mode d’authentification: mot de passe (spécification 7)
3.2.5 Choix d’une architecture (spécifications 8 à 10)
3.2.5.1 Position du problème
3.2.5.2 Différentes alternatives
3.2.5.3 Choix de l’architecture : 3-tier avec serveur Web
3.2.6 Des composants modulaires pour plus d’évolutivité (spécification 11)
3.2.7 Une interface simple et ergonomique (spécification 12 et 13)
3.3 Choix technologiques
3.3.1 Plate-forme de développement
3.3.2 Serveur de base de données
CHAPITRE 4 CONCEPTION ET IMPLÉMENTATION
4.1 Vue d’ensemble de QMA
4.2 Côté client : Applet
4.2.1 Contrôle utilisateur AuthControl
4.2.2 Contrôle utilisateur DisplayControl
4.2.2.1 Classe DisplayControl
4.2.2.2 Classe LSP
4.2.2.3 Classe Tunnel
4.2.2.4 Classe VRF
4.2.3 Contrôle utilisateur EventControl
4.2.4 Contrôle utilisateur ConfigControl
4.2.5 Contrôle utilisateur StatsControl
4.2.6 Contrôle utilisateur QMA
4.2.7 Exécution de l’ Applet
4.3 WebService
4.4 Modules
4.4.1 AuthManagement
4.4.2 DbManagement
4.4.2.1 Classe SNMP
4.4.2.2 Classe Database
4.4.2.3 Classe Control DB
4.4.3 MonitorManagement
4.4.3.1 Classe Trap_manager
4.4.3.2 Classe Stats_manager
4.4.3.3 Classe Control Monitor
4.4.4 LogManagement
4.5 Contrôleur de serveur
4.5.1 Onglet MPLS
4.5.2 OngletUser
4.6 Exemples de fonctionnement
4.6.1 Authentification réussie
4.6.2 Échec d’authentification
4.6.3 Visualisation des tunnels
4.6.4 Réception d’une trap
4.6.5 Création d’un nouvel utilisateur
4.7 Aspects non implémentés
CHAPITRE 5 EXPÉRIMENTATION
5.1 Méthode de suivi des bogues
5.2 Validation des spécifications
5.2.1 Méthodologie et environnement de test
5.2.2 Affichage de la topologie du réseau
5.2.3 Affichage des LSP
5.2.4 Affichage des tunnels
5.2.5 Affichage des VPN
5.2.6 Surveillance du réseau
5.2.7 Authentification
5.2.8 Multi utilisateur
5.2.9 Disponibilité
5.2.10 Confidentialité
5.2.11 Évolutivité
5.2.12 Simplicité, ergonomie
5.2.13 Indépendance des constructeurs
5.2.14 Impact minimum sur le réseau
CONCLUSION
RECOMMANDATIONS
ANNEXE 1 CODE MATLAB DE L’ALGORITHME HOLT-WINTERS
ANNEXE 2 GUIDE D’INSTALLATION DE QMA
ANNEXE 3 GUIDE D’UTILISATION DE QMA
ANNEXE 4 MODÈLE DE BASE DE DONNÉES DE QMA
BIBLIOGRAPHIE
Télécharger le rapport complet
