Soutenance mémoire
Télécharger le fichier pdf d’un mémoire de fin d’études
Format de l’adresse IP
Dans la version 4 du protocole IP (IPv4), une adresse est codée sur 32 bits et associée à une interface physique. Un point important de l’adressage IP est qu’il est hiérarchique : une adresse IP est constituée d’au moins deux parties, l’adresse du domaine auquel appartient l’interface et l’adresse de l’interface dans le domaine. L’adresse du domaine est une adresse officielle, qui lui permet d’être connue dans le réseau Internet (c’est-à-dire mondialement). L’adresse de l’interface dans le domaine peut être ou non subdivisée en une adresse de sous-domaine et l’adresse de l’interface dans le sous domaine, et ceci autant de fois que les 32 bits le permettent.
La première partie (adresse de domaine) doit être déclarée au centre d’information du réseau Internet (InterNIC : Internet Network Information Center). Il existe trois classes d’adresse de domaine, appelées A, B et C qui déterminent les tailles en bits de l’adresse du domaine. Elles sont respectivement de 8, 16 et 24 bits, ce qui permet d’avoir respectivement 224, 216 et 28 adresses d’interfaces possibles. La classe d’une adresse est déterminée par les 2 bits de poids fort de l’adresse.
Une adresse IP est généralement représentée par quatre entiers de 8 bits séparés par des points (x.y.z.w).
Certaines adresses de domaines de classe A sont réservée, et d’une manière générale les valeurs 0 et 2n-1 sont réservées, n étant la taille en bits de la partie de l’adresse que l’on considère (domaine, sous-domaine, interface). Cela laisse un nombre de valeurs possibles de 2n-2 pour chaque partie.
Protocoles de base d’IP
Citons quelques protocoles qui sont nécessaires au fonctionnement de base des réseaux IP :
• ARP (Address Resolution Protocol) : Il permet d’associer une adresse d’équipement physique (interface) à une adresse IP pour coopérer avec les couches inférieures [RFC826],
• ICMP (Internet Control Message Protocol) : Il permet le transport de messages relatifs au bon fonctionnement d’internet, et concerne principalement les informations de routage,
• DNS (Domain Name Service) : Ce protocole permet la résolution d’adresses nommées (FQDN – Fully Qualified Domain Name) en adresses IP. Par exemple il permet d’obtenir la réponse 195.83.132.133 à la question « www.laas.fr »,
Citons également TCP et UDP. Ils sont très largement utilisés, et décrits en détails dans les paragraphes suivants. Ces deux protocoles permettent le transport de données, via IP, entre deux applications exécutées sur les hôtes correspondants aux adresses source et destination de l’entête du paquet IP.
Les Protocoles UDP et TCP
UDP
UDP (User Datagram Protocol) est un protocole de communication de niveau ISO 4 (transport) sans connexion : Cela signifie qu’il n’y a aucune garantie qu’une trame UDP émise arrive à destination. Les trames UDP sont encapsulées par la couche réseau IP sous-jacente. Elles peuvent être de longueur quelconque, la couche IP se charge de leur fragmentation et de leur réassemblage de façon transparente.
La qualité de service offerte par UDP est la même que celle fournie par IP. UDP ajoute cependant quelques informations importantes à l’entête, outre la longueur des données utiles et un checksum : ce sont les numéros de port source et de port destination (figure 2). Ces numéros de port permettent de différencier plusieurs connexions ou services différents entre deux extrémités identiques dans le réseau IP, afin de pouvoir multiplexer les connexions entre deux mêmes machines.
UDP est principalement utilisé dans les réseaux locaux (dans lesquels la probabilité de perte d’un paquet IP est moindre) ce qui justifie la non-nécessité de connexion virtuelle (par opposition à TCP). Les services l’utilisant sont généralement NFS (Network File System), et NIS (Network Information Service), respectivement pour le partage de fichiers et la centralisation d’informations relatives aux réseaux. Ils sont en effet conçus pour fonctionner en mode déconnectés. De fait, ces services doivent détecter et éventuellement corriger eux-même les erreurs de transmission.
Le protocole UDP sert aussi à transporter des données autorisant des pertes mais ayant des contraintes fortes sur les délais. En effet un protocole en mode connecté procède à des retransmissions en cas de perte, ce qui peut considérablement augmenter le délai de bout en bout. Par exemple le protocole RTP (Real-Time Protocol) s’appuie sur UDP pour transporter des données de type communication audio.
TCP
Généralités
TCP/IP (Transmission Control Protocol on IP) est un protocole de transport. Ce protocole est utilisé à grande échelle sur Internet. C’est un protocole de niveau 4 (transport) qui assure un transfert bidirectionnel de données, de façon fiable et sans erreur, avec contrôle et retransmission des données effectués aux extrémités de la liaison.
Il est utilisé par les services réseaux qui nécessitent de transférer des données de façon fiable et sans erreur. Les services ou protocoles l’utilisant peuvent aller de la simple liaison type terminal (telnet, rlogin) interactive et à bas débit, aux transferts type FTP (File Transfert Protocol) de plusieurs Méga-Octets non-interactive, en passant par les requêtes HTTP (HyperText Transfert Protocol), le mail (SMTP : Simple Mail Transport Protocol), ou la visio-conférence. La notion de port permettant le multiplexage des données entre deux extrémités est la même que dans le protocole UDP.
La principale caractéristique de TCP est qu’il est un protocole dit en mode connecté. Cela signifie qu’avant tout échange de données, une connexion entre les deux extrémités de la liaison doit être établie. Une fois réalisée, cette connexion, qualifiée de virtuelle, demeure existante jusqu’à terminaison explicite et peut-être considérée comme un tube particulier offrant une communication sûre reliant les ports respectifs des deux extrémités. Cela s’oppose aux protocoles de transport sans connexion comme UDP.
Une transmission sans perte et sans erreur
Plusieurs mécanismes permettent aux couches supérieures de ne pas se préoccuper du contrôle et de la validité des données reçues par la couche de niveau transport TCP. Les mécanismes peuvent se résumer ainsi:
• Les tailles des paquets assemblés par la couche TCP et transmis à la couche IP ne correspondent pas forcément aux tailles des paquets reçus des couches supérieures (utilisateur, application), et ceci à des fins d’optimisation de la bande passante. Un paquet transmis par la couche TCP à la couche IP est appelé un segment de donnée,
• A l’émission d’un segment, un temporisateur est armé. A l’expiration de celui-ci, et si le corres-pondant n’a pas renvoyé d’accusé-réception pour ce segment, il est considéré comme étant perdu, et est retransmis,
• Quand la couche TCP reçoit une donnée du réseau, un accusé-réception est envoyé après un délai optionnel. Ce délai autorise la prise en compte de nouvelles données à envoyer, afin d’optimiser la bande passante. Il ne doit pas excéder 500ms, et est habituellement de 200ms,
• Chaque segment est accompagné de son checksum. Un segment arrivant avec un checksum inva-lide est détruit et ignoré. Le temporisateur de l’émetteur détectera alors la perte. Il est admis que moins de 1% des erreurs de transmissions sont dues à des erreur de checksum [STE94],
• Le protocole IP ne garantie pas que l’ordre de réception des paquets à la destination est le même que l’ordre d’émission à la source. Les segments TCP peuvent donc arriver à la destination dans le désordre, et dans ce cas, la couche TCP se charge de les remettre dans l’ordre afin que l’applica-tion reçoive correctement les données,
• Les segments reçus en double sont éliminés,
• Chaque extrémité de la connexion TCP a un tampon de réception de taille limitée. TCP assure qu’une extrémité n’enverra pas plus de données que ce que son correspondant ne peut recevoir.
Le routage IP: routage de proche en proche
La table de routage dans chaque routeur peut être positionnée par un opérateur, ou par un algorithme de routage. Si, une fois positionnée, le routage ne change pas, on le qualifie de routage statique, et au contraire, de routage dynamique si un algorithme est capable de le modifier en fonction des changements d’état du réseau.
Au minimum, chaque routeur doit avoir une vision partielle du réseau, limitée aux groupes d’adresses qui sont accessibles pour chacun de ses liens, permettant de transporter un paquet de proche en proche (next-hop). Une connaissance centralisée de l’ensemble des routeurs empruntés de la source jusqu’à la destination n’est pas nécessaire : Lorsqu’un paquet de destination inconnue (donc non locale) est reçu, le paquet est envoyé vers le routeur de frontière par défaut.
Les deux familles de protocoles IGP et EGP
Les IGP découvrent d’eux même la topologie du réseau pour trouver les chemins les mieux adaptés. Ils sont basés sur les algorithmes de type distance-vector qui n’ont qu’une vision partielle du réseau, ou sur les algorithmes de type link-state où chaque routeur construit une vision du domaine complet qu’il gère.
Les EGP travaillent principalement sur les routeurs de bordure des réseaux. Ils ne s’échangent pas les adresses de sous-réseaux.
Le routage dans les domaines IP l’Internet sont une collection de systèmes autonomes (AS : Autonomous System). Un système autonome est un réseau ou un groupe de réseaux placé sous une autorité administrative de routage unique.
Les AS utilisent à l’intérieur de leur domaine des protocoles de routage de type IGP tels que OSPF ou IS-IS (tableau 1). OSPF a été créé par l’IETF (Internet Engineering Task Force) et IS-IS par l’ISO (International Organization for Standardization). Ces deux protocoles calculent les routes par des algorithmes de type Link-State basés sur l’algorithme de plus court chemin de Dijkstra (I.4.4.2).
Les routeurs agissant dans un AS sont appelés Interior Gateway Router, et utilisent des protocoles de routage appelés Interior Gateway Protocols (IGP). D’autres routeurs permettent à différents AS de communiquer entre eux. Ils utilisent des protocoles de routage appelés Exterior Gateway Protocols (EGP).
Les protocoles de routage de type IGP
Un protocole de routage est un agent capable de modifier les tables de routage dans chaque routeur afin de rendre possible le transport des paquets de bout en bout, mais aussi de le faire le plus efficacement possible. Les principaux objectifs à atteindre par un protocole de routage sont:
• Optimisation (sélectionner le meilleur chemin selon les critères choisis),
• Robustesse et souplesse (pour faire face à tout imprévu),
• Convergence rapide (pour rapidement faire face aux boucles et aux pannes réseau),
• Simplicité (pour ne pas surcharger le réseau de données de contrôle).
En échangeant régulièrement des informations, les routeurs construisent une image de la topologie du réseau, qui n’est pas nécessairement connue initialement. Cela permet de créer les tables de routage.
Il existe deux grands types de protocoles de routage dynamique.
Distance-Vector
Le fonctionnement général d’un algorithme de routage de type distance-vector (vecteur de distance) est le suivant : Chaque routeur i associe un coût à chacun de ses liens vers un autre routeur j dans une table di(j). Ce coût peut représenter n’importe quel type de mesure (une constante, un prix, un délai, …). Chaque routeur i échange di avec ses voisins, et peut ainsi construire une nouvelle table Di(i,k) représentant le coût minimum pour atteindre un routeur k non directement connecté à i. Cette valeur est mise à jour à chaque réception de la table Dj(j,k), pour toutes les valeurs de k connues par le routeur voisin. Di i k = min di j+Dj j k (1)
Le choix du lien à emprunter pour aller de i à k est alors le lien (i,j) qui a permis la dernière mise à jour de la valeur actuelle de Di(i,k).
Les réseaux IP Multiservices et MPLS
Ces échanges de tables entre les routeurs se font tant que l’algorithme n’a pas convergé. Une fois la convergence atteinte, les échanges continuent afin de pouvoir détecter les pannes et reconverger vers une nouvelle table de routage.
• RIP [RFC1058], RIPv2 [RFC1388] (Routing Information Protocol) : la métrique utilisée est 1 par lien, 15 au maximum, 16 indique l’infini (ce qui limite le diamètre d’un domaine routé par RIP),
• IGRP, EIGRP ((Extended) Interior Gateway Routing Protocol, [CIS99]) : C’est une évolution de RIP par le constructeur CISCO, concernant principalement la métrique. Elle permet de tenir compte, en plus du nombre de routeurs intermédiaires, de la vitesse, du délai de transmission, de la charge et de la qualité des liens. La limitation à 16 est levée. Le partage de charge sur plusieurs routes est possible.
Avantages et Inconvénients
Le problème des algorithmes de routage de type distance-vector est la lenteur de leur convergence et l’instabilité (boucles de routage) de l’algorithme avant sa convergence. RIP résout cela en limitant les valeurs possibles de la métrique entre 1 et 15, 16 représentant une distance infinie, mais cela limite la taille du domaine. (E)IGRP lève cette limitation en introduisant d’autres techniques (Split Horizon, Poison-Reverse Updates [CIS99]).
Link State : OSPF
OSPF [RFC1247] (Open Shortest Path First : Le plus court chemin d’abord) est un protocole de routage dynamique et hiérarchique basé sur l’adressage IP. C’est un protocole de routage adapté aux grands réseaux à commutation de paquets (grand nombre de routeurs, redondance sur les chemins) dans lequel chaque routeur a une vision globale du réseau.
OSPF est un protocole de type Link-State (état de lien) : les données propagées par un routeur sont uniquement les informations sur ses liens avec ses voisins immédiats du même niveau hiérarchique.
Résumé de l’algorithme du Link-State
Lors de la phase d’initialisation de l’algorithme, chaque routeur découvre et identifie ses voisins immédiats (les routeurs voisins connectés à ses liens) grâce au protocole Hello. Des informations, appelées link-states sont alors construites. Elles contiennent des informations sur tous les liens du routeur, et notamment leur métrique. Les LSA (Link-State Advertisement: publication d’état des liens) regroupent ces informations pour les diffuser à grande échelle sur l’ensemble du domaine OSPF, de sorte que chaque routeur ait une vision (décalée dans le temps) de la topologie du domaine et de sa métrique. Chacun d’eux peut alors appliquer l’algorithme de Dijkstra du plus court chemin entre lui-même et l’ensemble des autres routeurs, pour construire sa table de routage IP.
Le routage dans les domaines IP
Principes de base d’OSPF
La diffusion des link-states de chaque routeur vers tous les autres routeurs peut engendrer un trafic de fond non négligeable sur le réseau. Un routeur appelé DR est alors désigné (Designated Router) pour centraliser puis redistribuer l’ensemble des link-states (LSA) sur tous les routeurs.
Pour diminuer encore le trafic de contrôle, le domaine OSPF est scindé en zones (OSPF areas), et chaque zone fonctionne de manière indépendante suivant l’algorithme décrit précédemment. Une zone particulière, appelée zone backbone (backbone area : zone fédératrice) joue le rôle d’interconnexion entre toutes les zones.
La métrique propagée dans les LSA est un coût sans dimension. Pour chaque lien, elle peut représenter son état (l’abscence de LSA indique une panne), la capacité, la capacité non-utilisée, le délai ou la charge, ou tout autre coût. Par exemple dans les routeurs CISCO la métrique par défaut est donnée par 108/débit(bits/s) (“plus le débit est grand, plus le saut est court”). Cette métrique peut également être une constante imposée par l’opérateur, arbitraire ou résultante d’un processus d’optimisation externe.
OSPF est également capable de différencier les classes de service, permettant ainsi un routage différent selon le type de trafic dans le réseau. Les tables de routages pouvant être différentes selon les classes de services, une métrique différente peut être utilisée pour chacune d’elle (I.6.2.4). Le partage de charge (Load Balancing) entre routes de longueur égales peut également être employé.
• Initialisation.
• Le routage initial pour permettre la diffusion des LSA et des informations de contrôle est positionné par l’opérateur. Les zones constituent un sous domaine avec une adresse de sous-réseau de l’AS,
• La diffusion des LSA se fait par un protocole multicast (multi-diffusion) afin de réduire le trafic de contrôle,
• Si un DR (routeur désigné) doit exister dans le réseau, l’élection se fait de proche en proche : chaque routeur se proclame routeur désigné, et au fur et à mesure de la réception des informations topologiques, celui-ci peut perdre cette élection si un routeur plus prioritaire s’est auto-proclamé.
• Pannes
L’élection d’un b-DR (backup-DR: DR de secours) est également organisée. le b-DR reste passif, mais est capable d’assurer les fonctions du DR en cas de panne de celui-ci.
La détection d’une panne d’un routeur de la zone se fait par les routeur voisins grâce aux paquets du protocole Hello. En effet, ces paquets sont régulièrement échangés pour rendre compte du bon fonctionnement des liens. Des LSA informant la suppression d’un lien sont alors propagés sur l’ensemble de la zone de sorte que les tables de routage soient recalculées.
Le routage entre les domaines IP: BGP
Le protocole BGP (Border Gateway Protocol) est un protocole de routage entre systèmes autonomes. Il est utilisé pour échanger les informations de routage entre AS dans le réseau Internet. Ces informations de routage se présentent sous la forme de la suite des numéros d’AS à traverser pour atteindre la destination.
Quand BGP est utilisé entre AS, le protocole est connu sous le nom de e-BGP (exterior BGP). Si BGP est utilisé à l’intérieur d’un AS pour échanger des routes entre les routeurs de bordure d’un même AS afin de le traverser, alors le protocole est connu sous le nom de i-BGP (interior BGP). BGP est un protocole très robuste et très scalable : les tables de routage BGP du réseau Internet comprennent plus de 90000 routes. Si BGP a atteint ce niveau de scalabilité, c’est essentiellement parce qu’il associe aux routes des attributs permettant de définir des politiques de routage entre AS.
Les routeurs de frontière communiquant par i-BGP doivent être complètement maillés (mais pas forcément directement connectés) afin de permettre l’échange des informations. Les évolutions de BGP utilisent cependant des techniques permettant de réduire le nombre de messages à échanger afin de réduire le trafic de contrôle dans les grands AS.
Les voisins BGP échangent initialement toutes leurs informations de routage par une connexion TCP. Les routeurs BGP n’envoient ensuite à leur voisins que des mises à jour des tables de routage lorsqu’un changement de route est détecté ou qu’une nouvelle route est apprise. Ainsi, les routeurs.
ASBR : Autonomous System Border Router; il exécute les protocoles EBGP, IBGP et IGP
ASR : Autonomous System Router; il exécute un ou plusieurs protocoles IGP (OSPF, IGRP, RIP)
BGP n’envoient pas de mises à jour périodiques mais ne diffusent que le chemin «optimal» vers un réseau destination.
BGP peut servir aussi à mettre en commun les tables de routages des différents algorithmes IGP pouvant exister dans différents sous-domaines d’un même AS, par exemple pour pouvoir router des données d’un sous-domaine à l’autre, sans sortir de l’AS.
Réseaux IP Multiservices et la gestion de QoS
Introduction
L’Internet de demain devra permettre le déploiement d’applications multimedia ayant des exigences spécifiques en terme de QoS (Quality of Service : Qualité de service). Certains services comme les services vocaux auront besoin d’un faible délai point à point et d’une faible gigue. D’autres, comme les trafics de données, nécessiteront des faibles taux de pertes ou d’erreurs, sans retransmission, avec éventuellement une certaine garantie de bande passante pour les trafics critiques comme les données transactionnelles.
Pour pouvoir garantir la QoS des flux transportés, il va donc falloir utiliser des mécanismes permettant de traiter de manière différenciée les différentes catégories de trafic dans les organes du réseau ainsi que des protocoles de signalisation de la QoS pour pouvoir allouer des ressources en fonction des besoins des applications.
On peut distinguer deux grandes problématiques pour la gestion de la QoS dans un réseau IP :
• La gestion des phénomènes de congestion :
Il s’agit un point fondamental pour garantir la QoS des flux. En effet, les mécanismes de gestion des QoS n’auront un impact effectif que lorsque le réseau sera chargé. Il existe deux grandes approches pour la gestion des congestions : les méthodes réactives et les méthodes préventives.
La philosophie du contrôle réactif est d’accepter un maximum de connexions. Lors de la congestion d’un équipement réseau (mesurée en terme de pertes, de délais et de remplissage des tampons), les sources réduisent leurs débits. Ainsi, dans le modèle Best-Effort (modèle « au mieux ») du réseau Internet actuel, la gestion du phénomène de congestion est faite de manière réactive par le mécanisme de fenêtre glissante (adaptation du débit) du protocole TCP. Toutefois, ce contrôle n’est pas adapté pour pouvoir offrir des garanties de QoS par exemple à des flux audio et vidéo temps réel : ils ne peuvent pas adapter leur débit.
A l’inverse, le contrôle préventif consiste à prendre des mesures « à priori », afin de minimiser l’apparition du phénomène de congestion et/ou pour qu’il n’affecte pas les services garantis. Ainsi, les techniques de contrôle d’admission ou de mise en forme des trafics (Policing, Shaping) permettent de réduire la fréquence des congestions tandis que les mécanismes de gestion de tampon (RED, WRED, etc.) permettent de respecter les QoS des services les plus prioritaires en cas de congestion.
• L’ordonnancement (Scheduling) des paquets est aussi un mécanisme fondamental pour garantir la QoS des flux transportés. Ceci est évident si on considère des flux hétérogènes : les rafales de certaines connexions peuvent perturber le trafic temps réel même s’il n’y a pas congestion. Ainsi, bien que la mise en oeuvre d’ordonnancements autres que FIFO (First in, First out : Premier Entré, Premier Sorti ou PAPS) soit difficile sur des routeurs à très haut débit, les équipementiers réseau fournissent de plus en plus des mécanismes sophistiqués réalisant un ordonnancement prenant en compte les classes de trafic (WRR, WFQ, etc).
Ces différents mécanismes de contrôle de congestion et d’ordonnancement des paquets sont présents dans toutes les architectures développées pour le contrôle de la QoS dans les réseaux IP. Historiquement, la première architecture qui a été proposée associe, comme ATM, une QoS à chaque flux que le réseau transporte. Il s’agit du modèle IntServ (Integrated Services : Service intégré). Pour des raisons de d’échelle principalement, la communauté Internet a également proposé un modèle appelé DiffServ (Differentiated Services : Services différenciés) dans lequel la QoS est associée à une agrégation de flots. Ce regroupement est appelé « classe de service ». Ces deux modèles de réseaux IP-Multiservices peuvent être utilisés avec le protocole de commutation MPLS (Multi Protocol Label Switching) qui permet un traitement très rapide des paquets sur les routeurs du coeur du réseau en remplaçant la fonction de routage IP par une fonction de commutation (switching), beaucoup plus adaptée au débit des réseaux de transport actuels. Le protocole MPLS encapsule ainsi le protocole IP.
Dans ce paragraphe, nous présentons les principaux mécanismes permettant la gestion de la qualité de service dans les réseaux IP. Puis nous décrivons les deux architectures proposées, IntServ et DiffServ. Enfin, nous présentons rapidement le protocole MPLS qui combine les avantages du monde IP avec ceux du monde ATM.
|
Table des matières
Chapitre I – Les réseaux IP Multiservices et MPLS
I.1 Introduction
I.2 Quelques éléments sur IP
I.2.1 L’adressage IP
I.2.2 Format du paquet IP
I.2.3 Format de l’adresse IP
I.2.4 Protocoles de base d’IP
I.3 Les Protocoles UDP et TCP
I.3.1 UDP
I.3.2 TCP
I.3.2.1 Généralités
I.3.2.2 Une transmission sans perte et sans erreur
I.3.2.3 Fonctionnement
I.4 Le routage dans les domaines IP
I.4.1 Le routage IP: routage de proche en proche
I.4.2 Les deux familles de protocoles IGP et EGP
I.4.3 Les « Autonomous System »
I.4.4 Les protocoles de routage de type IGP
I.4.4.1 Distance-Vector
I.4.4.2 Link State : OSPF
I.4.5 Le routage entre les domaines IP: BGP
I.5 Réseaux IP Multiservices et la gestion de QoS
I.5.1 Introduction
I.5.2 Les Principaux Mécanismes de Gestion de la QoS
I.5.2.1 Traffic Shaping (mise en forme du trafic)
I.5.2.2 Traffic Policing
I.5.2.3 Buffer Management
I.5.2.4 Ordonnancement des trafics (Traffic Scheduling)
I.5.2.5 Exemples d’ordonnanceurs
I.5.2.6 Les délais de transmission des paquets
I.5.3 Le modèle Integrated Service (IntServ)
I.5.3.1 Principe de IntServ
I.5.3.2 Les composants du modèle IntServ
I.5.3.3 L’ordonnanceur (scheduler)
I.5.4 Le modèle DiffServ (Differentiated Services)
I.5.4.1 Principe du modèle DiffServ
I.5.4.2 Les composants du modèle DiffServ
I.5.4.3 Exemple d’architecture DiffServ
I.6 Le protocole MPLS
I.6.1 Les principes de base
I.6.1.1 Introduction
I.6.1.2 Principes de MPLS
I.6.1.3 Principe MPLS
I.6.1.4 Fonctionnement de base du LSP
I.6.2 MPLS et l’ingénierie de trafic
I.6.2.1 Motivation
I.6.2.2 Concept de MPLS-TE
I.6.2.3 Ingénierie de trafic avec MPLS-TE
I.6.2.4 Routage des LSP et OSPF-TE
I.6.3 Mécanismes de protection dans MPLS
I.6.3.1 Détection des erreurs et mécanismes
I.6.3.2 Les mécanismes de protection et récupération
I.7 Problématique
Chapitre II – Modélisation différentielle du trafic
II.1 Théorie différentielle du trafic
II.1.1 Principe général de la théorie différentielle du trafic
II.1.2 Modèles dynamiques de systèmes markoviens élémentaires
II.1.2.1 Modèle dynamique de la file
II.1.2.2 Modèle dynamique de la file
II.1.2.3 Modèle dynamique de la file
II.1.3 Modèles dynamiques de systèmes élémentaires non markoviens
II.1.3.1 Modèle dynamique de la file
II.1.3.2 Modèle dynamique de la file
II.1.4 Modèles dynamiques de réseaux de files d’attente
II.1.5 La forme produit
II.1.6 Modèle différentiel d’un réseau
II.1.7 Réseau test (réseau double X)
II.2 Ordonnancement équitable
II.2.1 Paradigme GPS (Generalized Processor Sharing)
II.2.1.1 Définition de GPS
II.2.2 Etat de l’art
II.2.3 Approximation analytique de GPS par linéarisation pour 2 files
II.3 Conclusion
Chapitre III – Sources de trafic
III.1 Processus de génération aléatoire
III.1.1 Générateur aléatoire uniforme
III.1.2 Générateur aléatoire à partir d’une PDF
III.1.3 Processus ON-OFF
III.1.4 Processus IPP
III.1.5 Processus MMPP-N+1
III.1.6 Approximation d’un processus MMPP-N+1 par un processus MMPP-2
III.1.7 Processus corrélé basé sur le modèle
III.1.7.1 La corrélation
III.1.7.2 Génération des tailles d’image
III.2 Modèles de trafic agrégé
III.3 Générateurs de paquets
III.3.1 Générateurs et distribution empirique
III.3.2 Tests de validité pour les générateurs aléatoires uniformes
III.3.2.1 Caractéristiques des générateurs testés
III.3.2.2 Tests statistiques
III.3.2.3 Conclusion
III.3.3 Générateurs issus de distributions
III.3.3.1 Distribution exponentielle
III.3.3.2 Distribution Normale
III.3.3.3 Distribution Gamma
III.3.4 Sources Audio
III.3.4.1 G711, G726 et G729, RealAudio
III.3.4.2 : Sources vidéo
III.4 Statistiques sur des superpositions de sources de trafic
III.4.1 Sources Audio avec le Codec Audio G729 ON-OFF
III.4.1.1 Flux unitaire
III.4.1.2 Superposition en nombre constant de sources G729 ON-OFF
III.4.1.3 Codec G729 modélisé par un processus IPP
III.4.2 Sources Audio avec le Codec Audio G711 ON-OFF
III.4.2.1 Flux unitaire
III.4.2.2 Superposition en nombre constant de sources G711 ON-OFF
III.4.2.3 Superposition en nombre aléatoire de sources G711 ON-OFF
III.4.3 Sources Audio avec le Codec Audio G726-ON-OFF
III.4.3.1 Flux Unitaire
III.4.4 Sources Vidéo avec un processus modélisant le codec MPEG1
III.4.4.1 Flux unitaire
III.4.4.2 Superposition en nombre constant de sources Vidéo
III.5 Conclusion
Chapitre IV – TCP/IP
IV.1 Introduction
IV.2 TCP/IP Version NewReno
IV.2.1 Notations
IV.2.2 Algorithme
IV.2.2.1 Réception d’un paquet
IV.2.2.2 Emission d’un paquet
IV.2.3 Phénomène d’oscillations (silly window syndrom)
IV.2.4 Exemple
IV.2.4.1 Congestion des files d’attentes
IV.3 Quelques déclinaisons de TCP
IV.3.1 TCP-Pre-Taohe
IV.3.2 TCP-Tahoe
IV.3.3 TCP-Reno
IV.3.4 TCP-NewReno
IV.3.5 TCP-SACK
IV.4 Modèle différentiel par phase de TCP-NewReno
IV.4.1 Analyse qualitative
IV.4.1.1 La phase Slow-Start
IV.4.1.2 La phase Congestion Avoidance
IV.4.2 Modèle analytique différentiel de TCP-NewReno
IV.4.2.1 Phase Slow-Start sans perte
IV.4.2.2 Phase Congestion-Avoidance sans pertes
IV.4.3 Modélisation du Round-Trip-Time et des pertes dans le réseau
IV.4.3.1 Calcul de RTT(t) et de sa dérivée en fonction de la charge
IV.4.3.2 Calcul des pertes
IV.4.3.3 Analyse et calcul du retard pour arrêter l’émission
IV.4.4 Validations
IV.4.5 Conclusion
Chapitre V – Simulateur hybride
V.1 La difficulté des approches classiques
V.2 La Simulation Hybride
V.2.1 La simulation analytique
V.2.2 Le concept de Simulation Hybride
V.2.3 Deux principes de simulation hybride
V.2.4 Le simulateur hybride distribué DHS (Distributed Hybrid Simulator)
V.2.5 La simulation hybride
V.2.5.1 Algorithme général
V.2.5.2 Propagation des flots événementiels dans des noeuds analytiques
V.2.5.3 Calcul du taux de service moyen du service hybride
V.2.6 Exemples
V.2.6.1 Interconnexion hybride
V.2.6.2 Superposition hybride
V.3 Structure générale du simulateur DHS
V.3.1 Les noeuds, les flux et les flux-états
V.3.2 Le routage
V.3.2.1 Structure du routage
V.3.2.2 Routage de flux analytiques et de flux événementiels
V.3.2.3 Routage dynamique
V.3.3 Les événements
V.3.4 La simulation événementielle
V.3.4.1 Principe
V.3.4.2 Le paquet
V.3.5 La simulation analytique
V.4 Autres considérations sur la simulation
V.4.1 Statistiques
V.4.1.1 Rapport Stationnaire
V.4.1.2 Rapport Transitoire
V.4.1.3 Rapport de qualité de service sur les flots
V.5 Modélisation des réseaux IP Multi-Services et MPLS
V.5.1 Analogie avec les réseaux de files d’attente
V.5.2 Le modèle d’interface
V.5.2.1 Ordonnancement
V.5.3 Coeurs de réseaux MPLS
V.6 Validations
V.6.1 Réseau académique
V.6.1.1 Description des trafics
V.6.1.2 Interconnexion hybride
V.6.1.3 Superposition hybride
V.6.1.4 Résultats
V.6.2 Agrégation de sources de trafics
V.6.2.1 20 + 1 flux G711
V.6.2.2 Deux flux G711
V.6.3 Service D
V.6.4 Réseau réel et Interconnexion Hybride
V.6.4.1 Structure du réseau
V.6.4.2 La simulation
V.7 Conclusion
Chapitre VI – Environnement d’exécution distribuée
VI.1 Introduction
VI.2 Projets similaires
VI.3 Architecture de LANDA-HSN
VI.3.1 Modèle de la machine virtuelle
VI.3.2 Le modèle de communication
VI.4 Architecture de communication
VI.4.1 Introduction
VI.4.2 La communication locale
VI.4.2.1 Partage de mémoire
VI.4.2.2 Allocation en mémoire partagée
VI.4.2.3 Synchronisation
VI.4.2.4 Mécanisme de transfert de message en mémoire partagée
VI.4.2.5 Performances
VI.4.2.6 Implémentation
VI.4.3 Principes pour la communication distante
VI.4.4 Structure logicielle
VI.5 Utilisation de la couche Media
VI.5.1 Mode de communication
VI.5.2 Les canaux de communications (channel)
VI.5.2.1 La mémoire partagée (channel-shm)
VI.5.2.2 TCP (channel-tcp)
VI.5.2.3 Myrinet (channel-gm)
VI.6 Adaptation de MPICH sur l’environnement LANDA
VI.6.1 Introduction
VI.7 Simulation distribuée
VI.7.1 La parallélisation
VI.7.2 Equilibrage de charge
VI.7.3 Résultats préliminaires
VI.8 Conclusion
Conclusion
Références
Télécharger le rapport complet
