MPLS et la qualité de service

MPLS et la qualité de service

La qualité de service est aujourd’hui une caractéristique essentielle à tout réseau moderne. MPLS étant surtout utilisé avec des réseaux IP, elle se doit de supporter les deux architectures de qualité de service définies pour les réseaux IP, c’est-à-dire Intserv et Diffserv. L’ajout de RSVP comme protocole de distribution d’étiquettes n’est pas sans relation avec l’ajout du support de la qualité de service par la technologie MPLS. L’architecture de QoS Intserv pour les réseaux IP nécessite une réservation de ressources le long d’un chemin. Pour ce faire, le protocole RSVP transmet une requête à la destination. Le routeur de destination fait savoir au routeur précédent qu’il a les ressources suffisantes. Ce dernier répond à son tour au routeur qui le précède qu’il a les ressources et ainsi de suite jusqu’à la source de la requête.

Ceci est similaire à l’élaboration d’un LSP à la demande. Pour adapter RSVP au réseau MPLS, l’ajout d’un champ permettant le transport de l’ étiquette associée au flot pour lequel la réservation est faite est suffisant. Un LSP est ainsi associé à un flot de données pour lequel une réservation a été faite à l’ aide de RSVP. Le protocole LDP est en mesure de supporter toutes les méthodes de création de LSP discutées précédemment dont l’ établissement à la demande. Au début de MPLS, l’établissement d’un LSP à la demande consistait en une requête pour obtenir un circuit dont la destination est un réseau en particulier. Le support de la qualité de service a complexifié la façon de réaliser les LSP à la demande. LDP ne supportant pas les requêtes avec qualité de service, il a été adapté pour permettre la création de LSP selon certaines contraintes. CR-LDP (Constraint-based Routed- LSP) [RFC 3213] fournit les mécanismes nécessaires à l’établissement d’un LSP suivant un chemin précis. Le LER initiant la requête à l’aide de CR-LDP spécifie le chemin que doit suivre le LSP. Pour ce faire, il doit être au courant de l’état du réseau afin de déterminer un chemin qui correspond à certaines contraintes.

Ingénierie de trafic

L’ingénierie de trafic [RFC 2702] implique l’adaptation de l’acheminement du trafic aux conditions du réseau avec comme objectifs de fournir une bonne performance aux usagers et une utilisation efficace des ressources du réseau. Son rôle est de fournir aux ISP (Internet Service Provider) un contrôle efficace des flots de trafic transitant sur leurs réseaux. L’ingénierie de trafic, sur un réseau strictement IP, nécessite une connaissance des flots de trafics. La nature des réseaux IP fait en sorte que cette connaissance est basée sur des mesures complexes et incomplètes de l’état du réseau. Cette difficulté de réaliser une ingénierie de trafic efficace sur un réseau strictement IP provient de l’absence de circuits. MPLS ajoute aux réseaux IP cette caractéristique cruciale. La technologie MPLS est donc tout désignée pour supporter l’ingénierie de trafic. Le deuxième élément limitant l’ingénierie de trafic est la configuration manuelle des routeurs. Une autre approche permet de parvenir aux mêmes objectifs, c’est le routage par contraintes. Avec CR-LDP, un LSP est créé en fonction de contraintes. Ces contraintes peuvent être de nature à offrir une qualité de service, elles peuvent également être spécifiques à l’ingénierie de trafic. L’architecture de  qualité de service Intserv étant impossible à appliquer aux réseaux de grande taille, l’ approche Diffserv demeure la seule architecture réaliste.

Le routage de LSP par contraintes permettant l’ingénierie de trafic en plus de la qualité de service, le protocole RSVP n’était plus vraiment adapté aux nouveaux rôles de la technologie MPLS. Les promoteurs de RSVP ne lâchant pas prise, RSVP fut adapté au routage par contraintes et à l’ingénierie de trafic dans une nouvelle version appelée RSVP-TE (RSVP – Traffic Engineering) [RFC 3209] . Lorsque MPLS est utilisé pour l’ingénierie de trafic, le concept de « Traffic Trunk »est appliqué. Un Traffic Trunk est une agrégation de flots de trafic ayant la même classe de service et placée à l’intérieur d’un LSP (Figure 5). ll s’agit d’une représentation abstraite de trafic à laquelle certaines caractéristiques peuvent être associées. Le chemin que suit un Trafic Trunk peut être modifié, utiliser un LSP différent. Dans cette optique, le trafic entrant dans un réseau MPLS n’est pas associé à un LSP mais à un Traffic Trunk qui est lui-même associé à un ou des LSP.

Réseau de nouvelles génération et Voix sur MPLS

Tel le web et le courriel, la voix sur IP est vouée à un bel avenir. Les applications précurseurs de la voix sur IP, permettant un dialogue entre deux PC, sont loin d’être l’aboutissement de cette technologie. À terme, le but est l’élaboration d’une infrastructure de réseau unique permettant la convergence totale des réseaux à commutation de paquets (IP) et de circuits (voix). Les technologies de réseau par paquets et par circuits se séparent en deux plans nommés commutation (ou transport) et contrôle (ou signalisation). Le plan de commutation est constitué des fonctions permettant le transport de l’information. Dans un réseau IP il s’agit de décisions prises par chaque routeur, pour chaque paquet, à l’aide d’une table de routage. Dans un réseau de voix, il s’agit de fonctions associant les circuits d’entrées aux circuits de sorties. Pour sa part, le plan de contrôle est constitué de l’ensemble des fonctions fournissant les informations nécessaires au plan de commutation.

Dans un réseau IP, il s’agit des protocoles de routage élaborant les tables auxquels se fie le plan de commutation. Dans un réseau de voix, il s’agit de l’ensemble des fonctions de signalisation permettant à l’usager de faire une requête d’élaboration d’un circuit, la sélection du chemin que suivra ce circuit et la signalisation aux différents commutateurs des informations nécessaires à l’ association entrée-sortie. Dans un réseau IP, ces deux plans sont intégrés dans un ensemble homogène. Cette fusion des plans débouche sur une technologie de réseau dont le plan de contrôle ne sert qu’à l’élaboration de tables de routage. Ce plan de contrôle est peu flexible et ne permet pas une gestion efficace de la part du gestionnaire. Autrement dit, l’ingénierie de trafic sur ce type de réseau est pratiquement impossible. Cette approche de la réseautique considère que le réseau est stupide, se limitant à l’offre d’un service d’acheminement et que l’intelligence doit se retrouver à l’extérieur de celui-ci à l’aide d’application client serveur. Il en résulte une grande difficulté pour les gestionnaires de réseaux à fournir des services à valeurs ajoutées autres que l’acheminement.

Description du protocole SIP

Le protocole SIP est basé sur une architecture client serveur: la communication s’établit entre un UAC (User Agent Client) situé sur le terminal appelant et un UAS (User Agent Server) situé sur le terminal appelé. Chaque partie communicante est identifiée par une adresse de format URL (Uniform Resource Locator) qui se présente sous la forme sip://user@domain. L’utilisation d’une adresse de ce type permet à un utilisateur d’être mobile et de changer d’adresse IP au besoin. Si l’appelant connaît l’adresse de l’appelé, il peut le contacter directement. Si l’adresse de l’appelé n’est pas connue, l’adresse URL est utilisée conjointement avec un mandataire SIP (proxy SIP) servant d’intermédiaire lorsque l’adresse IP n’est pas connue (Figure 7). Avant que le mandataire SIP puisse servir d’intermédiaire, les utilisateurs doivent s’enregistrer auprès de ce dernier. À l’aide du nom de domaine de l’appelé, l’appelant interroge le DNS (Domain Name Service) pour obtenir l’adresse IP du mandataire situé dans le domaine auquel appartient l’appelé. L’appelant transmet ses messages au mandataire SIP de 1′ appelé qui sert alors de relais en acheminant les messages à 1′ adresse IP de 1′ appelé, enregistré au préalable. Pour implanter la logique décrite précédemment, SIP utilise plusieurs messages de requête, également appelés méthodes et six classes de messages de réponse.

Messages de requête

Les messages de requête requièrent qu’une action particulière soit prise par un autre UA ou par un mandataire SIP.

Ces requêtes sont :
• REGISTER : Cette requête est utilisée par un client désirant enregistrer son adresse IP auprès du mandataire auquel il est attaché.
• INVITE : Cette requête indique que l’utilisateur correspondant à l ‘URL spécifié est invité à participer à une session. Le corps du message décrit cette session (ex : audio encodé PCM (Pulse Code Modulation), suivant loi mu à 8000 échantillons/sec, en utilisant le protocole de transport RTP (Real Time Protocol)).
• ACK : Cette requête confirme que le terminal appelant a bien reçu une réponse définitive à sa requête INVITE et que la session peut débuter.
• BYE : Cette requête est utilisée pour terminer une session préalablement établie.
• CANCEL: Cette requête est envoyée par un terminal ou un serveur mandataire afin d’annuler une requête non validée par une réponse finale. Par exemple, si une machine ayant été invitée à participer à une session, et ayant accepté l’invitation ne reçoit pas de requête ACK, alors elle émet une requête CANCEL.
• OPTIONS :Cette requête est utilisée pour détecter la disponibilité ou interroger les capacités d’un UAC ou d’un UAS.

Messages de réponse

Un message de réponse est généré par un UAS ou par un serveur mandataire en répons à une requête transmise par un UAC. Les six classes de réponses sont :
• lxx Informational : Cette classe de réponse indique le statut d’un appel avant qu’il ne soit complété.
o 100 Trying: Un serveur mandataire peut transmettre cette réponse à l’appelant pour lui faire part qu’il tente de contacter l’appelé.
o 180 Ringing : La requête INVITE a été reçue et le UAS est en train de transmettre une alerte de type sonnerie. Si le UAS répond automatiquement, cette réponse n’a pas besoin d’être transmise.
• 2xx Sucees: Cette classe de réponse confirme le succès d’une requête.
o 200 OK: Cette réponse est transmise lorsqu’une requête de type INVITE a été acceptée. Ce message est également transmis en réponse aux requêtes REGISTER, BYE, CANCEL,
• 3xx Redirection : Messages de redirection transmis par le serveur mandataire
o 300 Multiple choices : Cette réponse retourne au UAC un message contenant plusieurs localisations possibles pour contacter le terminal demandé.
o 301 Moved permanently : Cette réponse contient la nouvelle adresse URL d’un contact. Cette nouvelle adresse est permanente.
o 302 Moved temporarily : Cette réponse contient une adresse URL pour le terminal demandé. Cette adresse URL est temporaire.
o 305 Use Proxy: Cette réponse retourne l’adresse URL d’un autre serveur mandataire devant être utilisé pour contacter le terminal désiré.
• 4xx Client Error: Classe retournant un message d’échec de la requête dû à une erreur du client.
o 400 Bad request: La requête n’a pas été comprise par le serveur
o 401 Unauthorized: La requête pour laquelle cette réponse est reçue
nécessite une autorisation du client.
o 403 Forbidden : La requête a été reçue, formulée correctement et a été comprise par le serveur qui ne rendra pas le service demandé par la requête.
• 5xx Server Error: Classe retournant un message d’échec de la requête dû à une erreur du serveur.
o 500 Server Internai Error
o 501 Not implemented: La requête reçue ne peut être exécutée car non
supportée par le serveur.
o 503 Service Unavailable : La requête demandée ne peut être traitée de façon temporaire.
• 6xx Global Error : Cette classe de réponses indique que le serveur mandataire sait que la requête sera un échec. La requête ne devrait donc pas être transmise à d’autres localisations. Seul le serveur mandataire responsable de l’usager identifié par le URL peut répondre avec cette classe.
o 603 Decline: Indique que l’appelé est occupé ou tout simplement qu’il ne désire pas prendre ses appels.
o 604 Does not exist Anywhere: L’usager spécifié dans la requête n’existe pas.
o 606 Not acceptable: Cette réponse peut être utilisée pour implanter une négociation. Cette réponse indique que certains aspects de la session ne sont pas acceptables par le UAS appelé.

Table des matières

ABSTRACT
REMERCIEMENTS
LISTE DES TABLEAUX
LISTE DES FIGURES
LISTE DES ABRÉVIATIONS ET DES SIGLES
INTRODUCTION
CHAPITRE 1 TECHNOLOGIES ABORDÉES 
1.1 Réseaux MPLS 
1.1.1 Les bases de la technologie de réseau MPLS
1.1.2 Distribution d’étiquettes
1.1.3 MPLS et la qualité de service
1.1.4 Ingénierie de trafic
1.1.5 Réseau de nouvelles génération et Voix sur MPLS
1.2 Signalisation SIP 
1.2.1 Description du protocole SIP
1.2.2 Serveur mandataire SIP (Pro x y SIP)
1.2.3 Réseaux VoiP avec gestion et caractéristiques intéressantes de SIP
CHAPITRE 2 ÉTAT DE L’ART 
2.1 Architectures SIP sur MPLS 
2.2 Contrôle d’admission d’appel 
2.2.1 Type de contrôle d’admission
2.2.2 Contrôle d’admission par gestion de ressources
2.2.3 Per Cali Reservation with Dynamic Path-based Bandwidth Allocation
CHAPITRE 3 RÉSEAUX DE SERVICES
3.1 Architecture proposée 
3 .1.1 L’évaluation des ressources par contrôle d’admission
3.2 Modélisation d’un réseau MPLS 
3.3 Configuration d’un réseau MPLS 
3.3.1 Définition des FEC
3.3.2 Définition des Trafic Trunk
3.3.3 Autres attributs MPLS généraux
3.3.4 Définition des LSP
3.3.5 Configuration des LER et LSR
3.4 Configuration du trafic de voix et de la signalisation SIP 
3.4.1 Définition de l’application voix
3.4.2 Définition de profils
3.4.3 Taux d’appels et de trafic
3.5 Configuration des équipements de téléphonie 
3.5.1 Configuration du Serveur SIP
3.5.2 Configuration des terminaux téléphoniques
CHAPITRE 4 IMPLANTATION DE L’APPLICATION DE VOIX ET DE SIP 
4.1 Description des modèles téléphone IP et mandataire SIP 
4.1.1 Modules Receiver et Transmitter
4.1.2 Module MAC et processus ethernet_ mac_ v2
4.1.3 Module ARP et processus ip _arp_ v4
4.1.4 Module IP, processus racine et enfants
4.1.5 Processus enfant MPLS MGR
4.1.6 Module IP _en cap et processus ip _ encap _ v4
4.1.7 Module UDP et processus udp_v3
4.1.8 Module TCP, processus racine et enfants
4.1.9 Module TPAL, processus racine et enfants
4.1.1 0 Module Application, processus racine et enfants
4.2 Processus applicatifs voix et SIP 
4.2.1 Résumé de connaissances reliées à l’établissement d’un appel
4.2.2 Fonctionnement du processus gna _ voice _ calling_ mgr
4.2.3 Fonctionnement du processus gna _ voice _ called _mgr
4.2.4 Fonctionnement du processus sip _ UAC _mgr
4.2.5 Fonctionnement du processus sip _ uac
4.2.6 Fonctionnement du processus sip_uas_mgr
4.2.7 Fonctionnement du processus sip_ UAS
4.3 Modification de processus 
4.3.1 Ajout d’un paramètre de configuration
4.3.2 Ajout d’une statistique à un processus existant
4.3.3 Configuration du premier cas de simulation
4.3.4 Modification du processus sip_UAS
CHAPITRE 5 ÉTUDES DES ALGORITHMES 
5.1 Présentation des algorithmes 
5.1.1 Algorithme ABW (Available BandWidth)
5.1.2 Algorithme DBP (Dynamic Bandwidth Prediction)
5.1.3 Algorithme DBP simplifié
5.1.4 Algorithme ERL (basé sur Erlang)
CHAPITRE 6 SCÉNARIOS DE TEST ET SIMULATIONS 
6.1 Théorie sur les distributions exponentielles 
6.2 Modèle de trafic 
6.2.1 Profil de trafic d’une entreprise
6.2.2 Validation de la configuration des taux de trafic
6.3 Objectif des algorithmes 
6.4 Étude de l’algorithme ABW (Available BandWidth) 
6.4.1 Étude comportementale de 1′ algorithme ABW
6.5 Étude de l’algorithme DBP (Dynamic Bandwidth Prediction) 
6.5.1 Étude comportementale DBP, paramètres NINc et Nooc
6.5.2 Étude comportementale DBP, paramètres BAcc et Booc
6.5.3 Étude comportementale DBP, paramètre PREJ
6.5.4 Conclusion sur le rôle des paramètres de l’algorithme DBP
6.6 Étude de l’algorithme DBP simplifié 
6.6.1 Étude comportementale DBP simplifié
6.6.2 Résumé et comparaison des algorithmes DBP
6.7 Étude de l’algorithme ERL 
6.7.1 Étude comportementale ERL, paramètre PR
6. 7.2 Étude comportementale, paramètre T
6.7.3 Étude comportementale ERL, paramètre PE
6. 7.4 Conclusion sur le rôle des paramètres de ERL
6.8 Comparaison des algorithmes 
CONCLUSION
BIBLIOGRAPHIE

Télécharger le rapport complet