Soutenance mémoire
Télécharger le fichier pdf d’un mémoire de fin d’études
Le RNIS (Réseau Numérique à Intégration de Services)
Bien que ce type de réseau ne soit plus d’actualité, Le RNIS a représenté une évolution remarquable de la génération des réseaux de télécommunication et informatiques qui ont commencé leur route vers la convergence [1]. Il consiste à intégrer plusieurs médias, dont la parole téléphonique et les données informatiques, offrant des services divers sur un même réseau. Au cours des années, le réseau a passé de RNIS bande étroite (RNIS-BE à un débit de 144 kbps dont 2 canaux de données B à 64 kbps chacune et un canal de signalisation D à 16 kbps) au RNIS large bande (RNIS-LB) permettant une transmission à haut-débit qui utilise les techniques ATM. RNIS utilise le protocole de signalisation SS7 (Signaling System n°7) à transfert de paquets sur un réseau sémaphore pour la gestion des signaux de commandes.
Architecture en couches
Plusieurs fonctionnalités doivent être implémentées pour que les différents équipements d’un réseau quelconque puissent effectuer en synergie le transfert des informations d’un bout à l’autre. Cela implique une complexité accrue de la mise en oeuvre du réseau, car il faut tenir compte de l’interopérabilité des plusieurs équipements reliés entre eux, ainsi que l’ordre dans lequel ils exécutent leur processus respectifs.
Dans le but de réduire cette complexité, une architecture en couche a été proposée pour découper ces processus en piles de protocoles afin de contrôler efficacement la transmission des flux de données dans le réseau à tous les niveaux [2]. 3 grandes classes d’architecture sont utilisées selon le type du réseau en question :
L’architecture OSI (Open System Interconnection) proposée par l’ISO comme architecture de référence constituée de 7 couches superposées.
L’architecture TCP/IP à 4 couches
L’architecture à 3 couches proposée par l’UIT-T pour les réseaux ATM.
Rôles de chaque couche
Couche physique : la couche physique englobe l’ensemble des règles et les équipements nécessaires à l’acheminement des données binaires. On y trouve les équipements réseaux qui traitent les signaux dans leur nature binaire, entre autres il y a les modems, les concentrateurs, les répéteurs, les supports physiques (câbles, faisceaux hertziens, fibres…).
Couche liaison de données : Il s’agit de la couche au niveau trame. Son rôle principal est de transmettre les données découpées en trames sur le support physique pour qu’elles arrivent à la destination voulue. On rencontre aussi des opérations de détection des éventuelles erreurs de transmission.
Couche réseau : Cette couche de niveau 3 est responsable du transfert des paquets d’un bout à l’autre. Ses principales attributions sont le contrôle de flux, la commutation ou le routage des paquets, et l’adressage. Les paquets peuvent traverser plusieurs équipements de niveau trois reliant deux ou plusieurs réseaux avant de parvenir à destination.
Couche transport : Cette couche est aussi appelée couche du niveau message (niveau 4) car elle est responsable de l’acheminement des informations sous leur forme de message. La couche transport effectue aussi le multiplexage de ces messages sur une même ligne de transmission, et aussi de l’opération inverse qui consiste à les démultiplexer pour être fournis aux couches supérieures du niveau des utilisateurs. Cette couche complète les travaux des 3 autres couches inférieures pour fournir aux utilisateurs leurs données à la qualité de service requise.
Couche session : La couche session fournit aux entités de présentation les moyens d’ouvrir, de fermer ou de maintenir une connexion entre les deux utilisateurs. C’est-à-dire qu’elle se charge de s’assurer qu’une connexion existe entre les interlocuteurs grâce à l’utilisation des sessions utilisateurs.
Couche présentation : La couche de niveau 6 a pour rôle de gérer la représentation syntaxique des données que les entités de la couche application peuvent comprendre. Son rôle est très important dans un environnement faisant intervenir plusieurs applications hétérogènes qui disposent de leur propre sémantique pour envoyer des informations.
Les architectures du niveau 2
On parle d’architecture du niveau 2 quand l’acheminement des données d’une source vers son destinataire se fait au niveau des trames. En d’autres termes, les données binaires sont découpées en plusieurs trames dans lesquelles est indiquée l’adresse de niveau 2 du terminal destinataire, qui servira d’indication aux commutateurs afin de les faire parvenir au récepteur indiqué. Les paquets, qui sont le plus souvent des paquets IP, seront donc encapsulés dans ces trames. Il n’y aura aucun besoin de décapsuler ces paquets lors de l’acheminement des données car ce dernier est effectué au niveau des trames. Dans toute la suite, nous allons examiner les réseaux les plus connus dans cette catégorie, notamment les réseaux à relais de trames (FR), les réseaux ATM (Asynchronous Transfer Mode), ainsi que les réseaux ethernet.
Les réseaux à relais de trame (Frame Relay Network)
Le relais de trames utilise le protocole de couche 2 pour le transfert des données (trames) qui contiennent les paquets fragmentés. Il s’agit de la solution qui précède les réseaux ATM, mais qui a pris succession à X.25 à la différence que les opérations de commutation sont ramenées de la couche 3 à la couche 2. Cela possède l’avantage d’augmenter la performance de la commutation, et présente un débit de transmission qui se mesure en mégabits par seconde (contre quelques kilobits par seconde pour le X.25), avec la possibilité de garantie de la qualité de service [2].
La commutation de trames
Comme on vient d’expliquer précédemment, dans ce type de commutation, les trames sont transportées d’un bout à l’autre au niveau de la couche liaison de données en utilisant les protocoles du niveau trame, et ce sans remonter à la couche 3. Les fonctionnalités de la couche 3 sont donc reportées à celle du niveau 2, entre autres l’adressage, le routage, et le contrôle de flux. De ce fait, tous les noeuds de commutation intermédiaires seront allégés lors de l’opération de décapsulation car elle s’effectue seulement sur les deux couches inférieures de l’architecture. Il y a donc diminution du nombre de niveaux à traverser pour chaque noeud, ce qui explique la performance de la commutation de trames (niveau 2) par rapport à la commutation de paquets (niveau 3).
Architecture du frame relay
Le relais de trame se compose de 2 réseaux logiques (celui des données utilisateurs et celui de la signalisation) multiplexés sur le réseau physique, qui constituent 2 plans distincts dans l’architecture : Le plan utilisateur et le plan de commandes [2]. Dans le plan de commande, régi par les protocoles Q.933 et Q.921, s’effectue toute procédure de signalisation, tel que l’établissement de la liaison virtuelle entre les deux bouts de connexion, tandis que la transmission des trames contenant les données utilisateurs est entreprise par le plan utilisateur. L’architecture suivante résume les rôles précédemment expliqués.
Les normes Ethernet
Les réseaux Ethernet partagés utilisent le MAC (Media Access Control) comme technique d’accès au support, en mettant en oeuvre le CSMA/CD (Carrier Sense Multiple Access) pour la gestion des collisions, dont le débit va de 1 à 10, 100 et 1000 Mbit/s. Les réseaux ethernet partagés ont pris successivement différents noms en fonction de leur norme :
Cheapernet : utilisation d’un câble fin avec conservation des capacités de transmission.
Starlan.
Fast Ethernet : réseaux à 100 Mbit/s.
Gigabit Ethernet, ou GbE : réseaux à 1000 Mbit/s. La vitesse de 10 000 Mbit/s (10 GbE) existe seulement en mode commuté.
Tous les réseaux Ethernet (10Base5, 10Base2, 10Broad36, 1Base5, 10BaseT, 10BaseF, 100BaseT, 1000BaseCX, 1000BaseLX, 1000BaseSX, 1000BaseT, 10BaseM, 10BaseX) utilisant la technique d’accès CSMA/CD sont normalisés IEEE 802.3.
Format d’une trame Ethernet
Dans des versions antérieures d’Ethernet, la structure d’une trame est différente de celle normalisée par IEEE 802.3 avec un mode d’adressage de 6 octets (contre 2 octets auparavant). Ce format est représenté par la figure 1.12.
Le protocole RTP
Le protocole RTP ou Real Time Protocol se charge, en compagnie de RTCP ou Real Time Control Protocol, de la transmission des paquets des applications temps-réel sur Internet. Ils s’assurent de délivrer ces paquets avec une qualité de service qu’on ne peut obtenir avec les autres protocoles de la couche application. C’est un exemple concret de la capacité de Internet à gérer la QoS.
Protocoles de la couche Transport
La couche transport est responsable de la transmission des informations sous forme de message. Ces messages sont multiplexés pour une même destination grâce à l’utilisation des ports. Deux protocoles de cette couche sont le protocole TCP et le protocole UDP, qui sont tous les deux très indispensables au fonctionnement d’Internet.
UDP (User Datagram Protocol)
UDP apporte le mécanisme de gestion de port au-dessus de la couche internet. Un port est un nombre entier positif utilisé par un service de la couche application et lui est propre. Le port joue le rôle d’identificateur afin qu’aucun chevauchement ne survienne avec le trafic des autres services, et ne représente aucune entité physique quelconque [2][3]. Les ports de la source et du destinataire sont spécifiés dans le paquet UDP encapsulé dans un datagramme IP selon le format de la figure 1.18.
La qualité de service ou QoS
Un des caractéristiques du protocole IP est qu’il n’est pas doté du mode orienté connexion. Autrement dit, la transmission d’un paquet IP peut se faire dès que l’adresse de destination est connue, et les paquets d’un même flot de données peuvent prendre des chemins différents [3]. Cela peut être considéré comme un atout. Néanmoins, l’ennui est qu’un tel comportement n’est pas très adapté pour supporter la qualité de service, élément vital des applications temps-réel.
Pour doter le réseau IP de la capacité à supporter ces types d’application, l’IETF a conçu deux modèles de gestion de la QoS sur les réseaux IP, à savoir :
Le Modèle IntServ ou Integrated Service
Le modèle IntServ est basé sur la réservation de ressources qui est exercée par le protocole RSVP ou Ressource ReserVation Protocol. Ce protocole se charge de spécifier les paramètres de réservation indiquant la QoS requise par les flots de données qu’un émetteur veut faire parvenir au récepteur.
RSVP utilise les deux messages PATH et RESV pour effectuer cette signalisation de routeur en routeur. PATH est le message initié par l’émetteur, qui permet de spécifier les caractéristiques du trafic qu’il va générer, tandis que le message RESV est à l’initiative du récepteur ayant reçu préalablement un message PATH qui, à son tour, spécifie la qualité de service requise et déclenche la réservation sur le même chemin pris par PATH.
|
Table des matières
CHAPITRE 1 VUE D’ENSEMBLE DES RESEAUX
1.1 Introduction
1.2 Fondement et principe de base des réseaux
1.2.1 Evolution historique et technique des réseaux
1.2.1.1 Commutation et routage de paquets
1.2.1.2 Le RNIS (Réseau Numérique à Intégration de Services)
1.2.2 Architecture en couches
1.2.2.1 Modèle de référence
1.2.2.2 Rôles de chaque couche
1.2.3 Les réseaux informatiques
1.3 Les architectures du niveau 2
1.3.1 Les réseaux à relais de trame (Frame Relay Network)
1.3.1.1 La commutation de trames
1.3.1.2 Architecture du frame relay
1.3.2 Les réseaux ATM
1.3.2.1 Architecture du réseau ATM
1.3.2.2 Format d’une cellule ATM
1.3.3 Les réseaux Ethernet
1.3.3.1 Les normes Ethernet
1.3.3.2 Format d’une trame Ethernet
1.4 Les architectures du niveau 3 : Les réseaux TCP/IP
1.4.1 Architecture du réseau TCP/IP
1.4.2 Quelques protocoles de la couche application
1.4.2.1 Le protocole IGMP
1.4.2.2 Le protocole RTP
1.4.3 Protocoles de la couche Transport
1.4.3.1 UDP (User Datagram Protocol)
1.4.3.2 TCP (Transmission Control Protocol)
1.4.4 Le Protocole IP
1.4.4.1 Format d’un datagramme IP
1.4.4.2 Rôle de ARP/RARP
1.4.4.3 Routage IP
1.4.4.4 La qualité de service ou QoS
1.5 Conclusion
CHAPITRE 2 LE RESEAU MPLS
2.1 Introduction
2.2 Origine du protocole MPLS
2.2.1 Intégration IP sur ATM
2.2.2 Les protocoles pré-MPLS
2.3 Architecture du réseau MPLS
2.3.1 Plans de contrôle et de données
2.3.2 Les labels
2.4 Principe de la commutation de labels
2.4.1 Elements principaux de la commutation
2.4.1.1 LSR (Label Switched Router) et LER (Label Edge Router)
2.4.1.2 LSP ou Label Switched Path
2.4.1.3 FEC ou Forward Equivalence Class
2.4.1.4 Les tables MPLS
2.4.2 Distribution de labels par LDP ou Label Distribution Protocol
2.4.2.1 Les modes MPLS
2.4.3 Exemple pratique
2.5 Applications de MPLS
2.5.1 Architecture de QoS sur MPLS
2.5.1.1 Politique de gestion de QoS
2.5.1.2 Modèle DiffServ dans le réseau MPLS
2.5.2 MPLS Traffic Engineering
2.5.2.1 Puissance du Traffic Engineering
2.5.2.2 Architecture du MPLS Trafic Engineering
2.6 Conclusion
CHAPITRE 3 SYSTEMES DISTRIBUES ET ARCHITECTURE
3.1 Introduction
3.2 Architecture Client-Serveur
3.2.1 Modèle général
3.2.1.1 Interface utilisateur
3.2.1.2 Applications
3.2.1.3 Les données
3.2.1.4 Les middlewares
3.2.2 Architecture un-tiers
3.2.3 Architecture deux-tiers
3.2.4 Architecture trois-tiers
3.2.5 Récapitulation
3.3 Architecture parallèle
3.3.1 Classification de Flynn (J. Michael)
3.3.1.1 Single Instruction Single Data (SISD)
3.3.1.2 Single Instruction Multiple Data (SIMD)
3.3.1.3 Multiple Instruction Single Data (MISD)
3.3.1.4 Multiple Input Multiple Data (MIMD)
3.3.2 Classification selon le réseau d’interconnexion
3.3.2.1 Réseau à topologie linéaire
3.3.2.2 Réseau à bus partagés
3.3.2.3 Réseau à Crossbar
3.3.2.4 Réseau à interconnexion en étoile
3.3.2.5 Réseau à interconnexion en anneau
3.3.2.6 Réseau à interconnexion en hypercube
3.3.2.7 Réseau à topologie en arbre
3.3.2.8 Réseau à interconnexion en mesh
3.3.2.9 Réseau à interconnexion en graphe complète
3.3.2.10 Récapitulation des performances
3.4 Systèmes distribués
3.4.1 Fondement des systèmes distribués
3.4.2 Systèmes à objets distribués
3.4.2.1 Objets distribués avec RMI
3.4.2.2 Architecture CORBA
3.4.3 Système Peer To Peer (P2P)
3.4.3.1 Architecture P2P
3.4.3.2 Types de systèmes P2P
3.4.4 Architecture orientée service (SOA) et Web Service
3.4.4.1 WS-SOAP et WS-REST
3.4.4.2 Protocole SOAP
3.4.4.3 Langage WSDL
3.4.5 Grid Computing
3.4.5.1 Les types de grid et exemples
3.4.5.2 Notion d’organisations virtuelles (Virtual Organizations)
3.4.5.3 Architecture d’une grid
3.4.5.4 Les Grid Services
3.5 Conclusion
CHAPITRE 4 LOAD BALANCING : MODELES MATHEMATIQUES ET ALGORITHMES
4.1 Introduction
4.2 Communication entre noeuds
4.2.1 Communication synchrone/asynchrone
4.2.2 Communication avec blocage/sans blocage
4.3 Modèles d’équilibrage de charge
4.3.1 Modèle d’équilibrage statique
4.3.1.1 Formulation du problème
4.3.1.2 Approche de l’équilibrage par la théorie de jeu coopératif
4.3.2 Modèle d’équilibrage dynamique
4.3.2.1 Effet du temps de latence
4.3.2.2 Modèle général continu de l’équilibrage
4.3.2.3 Détermination de pij
4.4 Conclusion
CHAPITRE 5 MISE EN PLACE ET ANALYSE DE PERFORMANCE D’UNE GRILLE DE CALCUL
5.1 Introduction
5.2 Vue globale du système
5.2.1 Système à réaliser
5.2.2 Présentation des entités
5.2.3 Interactions entre les entités
5.2.3.1 Client-Dispatcher
5.2.3.2 Dispatcher-Noeuds d’exécution :
5.2.3.3 Interactions entre noeuds d’exécution :
5.3 Réseau d’implémentation
5.3.1 Organisation A
5.3.1.1 Client
5.3.2 Organisation B
5.3.3 Organisation Virtuelle formée
5.3.4 Topologie du réseau de transport
5.3.4.1 Présentation de GNS 3
5.3.4.2 Topologie T1 : Réseau pur IP
5.3.4.3 Topologie T2 : Réseau IP/MPLS
5.4 Services du niveau application
5.4.1 Client
5.4.1.1 Objet de la simulation MC
5.4.1.2 Paramètres de la simulation
5.4.1.3 Interface de l’application
5.4.2 Dispacther
5.4.2.1 Web Service RESTful de soumission de tâches
5.4.2.2 Gestion et répartition des tâches
5.4.3 Noeud d’exécution
5.5 Résultats et interprétation
5.5.1 Paramètres Matlab
5.5.2 Environnement de la simulation
5.5.3 Simulation 1 : {T1, AL1}
5.5.4 Simulation 2 : {T1, AL2}
5.5.4.1 Observations des résultats
5.5.4.2 Atout du modèle
5.5.4.3 Désavantage du modèle
5.5.5 Simulation 3 : {T1, AL2, AL3}
5.5.5.1 Résultat
5.5.5.2 Limites de la simulation 3
5.5.6 Simulation 4 : {T2, AL2, AL3}
5.5.6.1 Amélioration apportée
5.5.6.2 Comparaison des performances
CONCLUSION GENERALE
ANNEXES
ANNEXE 1 : Solution d’optimisation dans un jeu coopératif
ANNEXE 2 : Quelques propriétés de la file M/M/1
ANNEXE 3 : A propos de Globus Toolkit
BIBLIOGRAPHIE
Télécharger le rapport complet
