Approche en Ligne pour une Gestion Autonome et Décentralisée des Réseaux MPLS-DiffServ

Transcription

1 Approche en Ligne pour une Gestion Autonome et Décentralisée des Réseaux MPLS-DiffServ Rana Rahim-Amoud, Leila Merghem-Boulahia, et Dominique Gaiti ICD/ LM2S, CNRS FRE 2848, Université de technologie de Troyes rana.amoud, leila.boulahia, Résumé La combinaison entre DiffServ et MPLS présente une stratégie très attrayante pour les fournisseurs de service réseau puisqu elle permet d assurer le partage de charge et la qualité de service demandée par les clients. Toutefois, la gestion de ce type de réseau n est pas une fonction simple et ne peut pas être réalisée manuellement. Ce papier propose une approche en ligne, basée sur les Systèmes Multi-Agents, dans le but d assurer une gestion autonome et décentralisée du réseau MPLS- DiffServ. Pour répondre aux exigences de la QoS, nous proposons une stratégie de gestion des LSP, basée sur une approche fondée sur le trafic et dépendant des conditions du réseau. Le but de notre stratégie est de diminuer le nombre de LSP et d opérations de signalisation dans le réseau MPLS. Les tests illustrés montrent l efficacité de notre approche. 1 Introduction Avec l évolution des réseaux, plusieurs nouveaux paradigmes ont été proposés et mis en application pour garantir une meilleure qualité de service (QoS). Parmi ces paradigmes, on trouve DiffServ (Differentiated Services) [6] et MPLS (Multi Protocol Label Switching) [12]. La combinaison entre DiffServ et MPLS permet de satisfaire les utilisateurs en fournissant la QoS demandée. Cependant, de nouvelles techniques doivent être conçues pour gérer cette combinaison afin de fournir la QoS demandée tout en optimisant l utilisation des ressources du réseau. MPLS introduit une référence (label), au niveau du routeur d entrée, pour pouvoir commuter les paquets. Ces routeurs d extrémité sont appelés les LER (Label Edge Router). Les routeurs intermédiaires sont des routeurs - commutateurs et sont appelés les LSR (Label Switch Router). Le chemin suivi par les flots est appelé LSP (Label Switched Path). Plusieurs protocoles de distribution de labels, tels que LDP, CR-LDP (Constraint based-ldp) et RSVP-TE (ReSource reservation Protocol avec Traffic Engineering) [7], peuvent être utilisés pour établir, maintenir et libérer les LSP. Une des plus importantes applications de MPLS est l ingénierie de trafic qui permet de manipuler le trafic afin d optimiser l utilisation des ressources et les performances du réseau [5]. Toutefois, MPLS ne permet pas seul une différentiation de service et a donc besoin d être complété par une technologie capable de fournir une telle différentiation : DiffServ. Cette recherche est co-financée par le Conseil Régional Champagne Ardenne et le Fonds Social Européen.

2 Dans ce papier, nous proposons une nouvelle approche en ligne pour automatiser et décentraliser la gestion du réseau MPLS-DiffServ : DATA (Decentralized and Autonomous Traffic engineering management Approach). DATA introduit un Système Multi-Agents (SMA) dans le réseau MPLS. En se basant sur l état du réseau, le SMA prend les décisions convenables telles que créer, supprimer ou re-dimensionner un LSP et les applique au réseau. Le but de notre stratégie est de diminuer le nombre de LSP et le nombre d opérations de signalisation dans le réseau MPLS. En utilisant des LSP différents pour acheminer les trafics des différentes classes de services, ces classes peuvent être traitées différemment. Ainsi, le réseau physique est divisé en des réseaux virtuels multiples, un par classe. Ces réseaux virtuels peuvent avoir différentes topologies et ressources [14]. Dans DATA, trois réseaux MPLS virtuels sont définis pour les trois types de classes de service EF (Expedited Forwarding), AF (Assured Forwarding) et BE (Best Effort). La capacité de chaque lien physique est divisée entre ces réseaux MPLS virtuels. Ce papier est organisé comme suit. La section 2, présente les différents outils existants pour automatiser la gestion dans MPLS. Dans la section 3, nous décrivons DATA. Puis, dans la section 4, nous présentons nos expérimentions et les résultats obtenus. La conclusion et les perspectives sont fournies dans la section 5. 2 Automatisation de la Gestion dans MPLS : L Existant Plusieurs propositions ont eu lieu dans la littérature pour gérer les réseaux MPLS dont quelques unes sont décrites dans ce qui suit. TEAM (Traffic Engineering Automated Manager) [13] est un gestionnaire autonome pour les réseaux MPLS-DiffServ. Il est composé de trois outils : un outil d ingénierie de trafic appelé TET (Traffic Engineering Tool), un outil de mesures et d évaluation de la performance appelé MPET (Measurement and Performance Evaluation Tool) et un outil de simulation appelé ST (Simulation Tool). TET est un serveur central responsable de la gestion des ressources et des routes dans le réseau et est soutenu par les deux autres outils. L architecture de TEAM est très intéressante, toutefois, elle est basée sur un serveur central, ce qui représente une solution lourde et pose un problème de passage à l échelle. TEQUILA (Traffic Engineering for QUality of service in the Internet, at LArge scale) [1] est un projet de recherche européen qui a pour but de fournir une QoS de bout en bout dans un Internet basé sur DiffServ. L architecture de TEQUILA est avantageuse, cependant elle est basée sur un système central. RATES (The Routing and Traffic Engineering Server) [3] est un serveur central développé, dans les laboratoires Bell, pour MPLS-TE. RATES est un outil avantageux d ingénierie de trafic, mais il est basé sur un serveur central et est destiné uniquement à l établissement des LSP avec une garantie de bande passante. Nous remarquons qu aucune solution proposée ne prend en considération la différentiation de service dans MPLS tout en se basant sur une approche décentralisée. Le présent article vise à apporter une solution décentralisée supportant la différentiation de service, pour assurer la gestion du réseau MPLS.

3 3 DATA : Approche en Ligne pour une Gestion Autonome et Décentralisée du réseau MPLS-DiffServ Afin de rendre un réseau autonome, nous pensons qu il est nécessaire de lui attribuer les caractéristiques suivantes : la distribution, la décentralisation, la décomposition des tâches, la coopération et l adaptabilité. Les SMA constituent un outil intéressant pour rendre les réseaux autonomes puisqu ils fournissent toutes ces caractéristiques. En effet, un SMA se compose d un ensemble d agents qui sont des processeurs autonomes qui prennent des décisions en se basant sur des informations locales [8]. Leurs principales caractéristiques, qui permettent d automatiser les réseaux, sont définies dans la section suivante. 3.1 Les Principales Caractéristiques des Agents Permettant de Rendre un Réseau Autonome Dans ce qui suit, nous détaillons les caractéristiques qui nous semblent essentielles pour atteindre un comportement autonome et nous démontrons que toutes ces caractéristiques sont, en effet, offertes par la solution multi-agents 1 : La Distribution et la Décentralisation. La nature distribuée des réseaux exige que la solution, nécessaire pour les rendre autonomes, soit elle aussi distribuée. De plus, nous pensons que cette solution devrait être décentralisé, ce qui permet à chaque composant d agir indépendamment sans avoir besoin d informations sur le réseau global. L approche multi-agents est, par définition, distribuée et décentralisée. Aucun agent ne possède une vision globale du système et les décisions sont prises d une manière totalement décentralisée. La Décomposition des Tâches et la Coopération. Nous pensons que la solution devrait être capable de partager et de décomposer les tâches entre plusieurs composants de façon à avoir des composants simples. De plus, une coopération est nécessaire entre ces composants pour garantir une connectivité de bout en bout. Un des aspects intéressants de l approche multi-agents est sa capacité à distribuer l intelligence entre les différents agents composant le système. Ceci implique qu un agent peut s occuper de quelques tâches individuellement mais ne peut pas tout faire par lui-même. Il doit coopérer avec les autres agents et compter sur leur aide pour accomplir sa tâche et obtenir de meilleurs résultats. L adaptabilité Un réseau autonome, comme n importe quel autre système autonome, devrait être capable de changer son fonctionnement (sa configuration, son état et ses fonctions). Le SMA permet d offrir cette caractéristique car un agent est réactif, pro-actif et capable d apprendre. En effet, un agent a la possibilité de réagir à certains événements, d établir des plans de fonctionnement et d évaluer l exécution de ces plans pour obtenir un meilleur fonctionnement. 1 Nous avons défini une partie de ces caractéristiques dans [11].

4 3.2 Architecture et Organisation des Agents La gestion des LSP signifie non seulement la création, le maintien et la libération des LSP, mais également l adaptation des LSP aux nouvelles demandes de ressources et la distribution du trafic entrant sur ces LSP. Des LSP devront alors être re-dimensionnés tandis que d autres seront créés pour acheminer de nouveaux trafics. Afin de gérer et de contrôler efficacement le réseau et de réaliser une solution décentralisée, nous avons décidé d introduire un agent dans chaque routeur du domaine MPLS. Ainsi, un agent d extrémité est introduit dans chaque routeur LER et un agent intermédiaire est introduit dans chaque routeur intermédiaire LSR. Ces agents ont la même architecture et forment ensemble un SMA. Chaque agent interagit avec ses voisins adjacents situés à un seul saut et avec les agents d extrémité, mais également avec le routeur ou le commutateur sur lequel il est introduit. Pour gérer un réseau, plusieurs activités doivent être réalisées [1] : collecter les données de gestion, interpréter ces données et contrôler les éléments du réseau. Pour arriver à cette fin, l architecture de chaque agent comporte deux entités : l entité de collection et l entité de gestion. L architecture comporte également une base de données (BD), qui est partagée entre ces deux entités (Fig. 1). L Entité de Collection. Cette entité collecte uniquement les informations concernant les interfaces du routeur dans lequel l agent est introduit. Elle collecte les informations concernant la bande passante disponible des liens physiques et des LSP qui traversent ce routeur ainsi que les informations concernant la topologie du réseau local telles que les nouveaux LSP créés, les LSP libérés, l état d utilisation des LSP, etc. L Entité de Gestion. Cette entité détermine quand et où un LSP devra être créé. En effet, en ayant accès à la base de données, l entité de gestion utilise les informations collectées afin de prendre les décisions les plus appropriées aux demandes qui arrivent et de mettre en application cette décision. L entité de gestion comporte deux sous-entités : la sous-entité de gestion des routes et la sous-entité de gestion des ressources (Fig.1). La Sous-entité de Gestion des Routes. Le rôle de cette sous-entité est d établir les nouveaux LSP sur le réseau physique. Plus précisément, lors de la création d un nouveau LSP, le rôle de cette sous-entité est de choisir, sous les conditions actuelles, la route la plus appropriée pour établir le LSP tout en répondant aux exigences de la QoS. La Sous-entité de Gestion des Ressources. Le rôle de cette sous-entité est de trouver la meilleure manière pour acheminer le trafic entrant. Selon la charge du réseau et l état actuel des trois topologies virtuelles, cette sous-entité décide d assigner le trafic entrant à un LSP préexistant, de re-dimensionner un LSP préexistant et d augmenter les ressources qui lui sont allouées ou d établir un nouveau LSP.

5 Entité de collection BD Gestion des routes de LSP Gestion des ressources de LSP Base de donnée Entité de gestion Fig. 1. Architecture de notre agent 3.3 La Stratégie de Gestion des LSP Le but principal de cette stratégie est de gérer les LSP selon les conditions actuelles du réseau. Elle s occupe de la conception du réseau et des traitements effectués à l arrivée des nouvelles requêtes. Choix de l approche appropriée pour concevoir un réseau MPLS. Pour concevoir un réseau MPLS, des approches hors ligne et en ligne ont été proposées. Les approches hors ligne sont basées sur des évaluations des demandes du trafic. D après Kodialam [9], les approches hors ligne ne conviennent pas aux réseaux MPLS car il est impossible d avoir une bonne prévision du trafic Internet. Nous avons alors évité ces approches. Contrairement aux approches hors ligne, les approches en ligne calculent les chemins à chaque arrivée d une demande. Deux différentes méthodes en ligne peuvent être utilisées pour établir des LSP dans un réseau MPLS. La première est fondée sur la topologie alors que la deuxième est fondée sur le trafic. En utilisant une approche fondée sur la topologie, les LSP sont établis à l avance lors de la création de la table de routage [2]. Dans cette approche, les LSP existent déjà avant que le trafic ne soit transmis, ainsi un LSP peut être créé et maintenu sans qu aucun trafic ne l utilise. Par contre, en utilisant une approche fondée sur le trafic, la création des LSP dépend du trafic entrant. Quand une nouvelle demande pour un flot de trafic ou pour un traffic trunk (agrégation de flots de trafic appartenant à la même classe) survient, le chemin correspondant est établi et maintenu jusqu à ce que la session devienne inactive [13]. L approche fondée sur le trafic permet alors de n établir que les LSP nécessaires, ce qui montre que cette approche est plus avantageuse que l approche fondée sur la topologie et c est la raison pour laquelle nous l avons adoptée dans DATA. La solution, qui nous paraît la plus logique et la plus avantageuse pour concevoir un réseau MPLS, est de commencer par une attribution initiale nulle (aucune bande passante n est réservée) pour tous les routeurs d extrémité dans chacune des trois topologies virtuelles. L arrivée des requêtes initiales déclenchera le processus de construction des topologies réelles. Un changement de topologie aura lieu, par conséquent, quand un nouveau LSP est créé ou bien libéré suite à une requête. Comme la conception est fondée sur le trafic, une requête pourrait consister à une demande de bande passante (un flot de trafic ou un traffic trunk) ou une demande de libération de bande passante (session inactive).

6 Traitement des Requêtes. Dans cette section, nous étudions les traitements à effectuer à l arrivée de chaque type de requête. Requête 1 : Demande de Libération de Bande Passante. Considérons qu un routeur d entrée reçoit une demande de libération de bande passante. L agent d extrémité, qui a reçu la demande, vérifie si la capacité du LSP, dans lequel a été acheminé le trafic, est égale à la bande passante à libérer. Si c est le cas, l agent d extrémité libère alors le LSP correspondant. Par contre, si la bande passante à libérer est inférieure à la capacité du LSP, l agent d extrémité libère la bande passante réservée, ce qui se traduit par l augmentation de la bande passante disponible du LSP correspondant avec la valeur libérée. Requête 2 : Demande de Bande Passante. Considérons que la nouvelle requête consiste en une demande de bande passante entre une paire de routeurs du domaine MPLS exigeant un certain niveau de QoS. La stratégie pour ce cas est donnée par l organigramme présenté dans Fig. 2. La première étape consiste à vérifier l existence d un LSP entre les deux routeurs en question dans la topologie virtuelle correspondante (EF, AF ou BE) (2) 2. Cette vérification est réalisée par l agent d extrémité qui a reçu la demande. Si un LSP existe déjà entre ces deux routeurs, la seconde étape consiste alors à comparer la bande passante disponible sur le LSP existant à la bande passante demandée (3). Si l agent d extrémité trouve que la bande passante disponible sur le LSP est supérieure à la bande passante demandée, il assigne la bande passante demandée par la nouvelle requête à ce LSP. La bande passante disponible sur le LSP sera, par conséquent, réduite (4). (1) Nouvelle demande de bande passante (2) LSP? non 1. Créer un LSP 2. Rejeter la demande (5) oui non (3) (4) BP disponible > BP demandée oui Utiliser le même LSP non BP demandée oui Augmenter la capacité du LSP <= B disp (7) (6) BP: Bande passante B disp =BP disponible sur le lien physique + BP disponible sur le LSP Fig. 2. Stratégie de gestion des LSP pour une nouvelle demande de bande passante Si la bande passante disponible est inférieure à la bande passante demandée, le SMA vérifie la possibilité de re-dimensionner le LSP. S il y a suffisamment 2 Ces valeurs indiquent les étapes sur la figure 2.

7 de bande passante disponible dans la partition correspondante de la topologie virtuelle, la bande passante demandée sera comparée à B disp qui est la somme de la bande disponible sur le lien physique et de la bande passante disponible sur le LSP existant(6). Si la bande passante demandée est inférieure ou égale à B disp sur un lien physique que le LSP existant traverse, la comparaison est faite pour le lien suivant et ainsi de suite jusqu à atteindre le routeur de sortie. Le SMA décide alors d augmenter la capacité du LSP, par une valeur égale à la différence entre la bande passante demandée et la bande passante disponible sur le LSP, pour qu il devienne capable d acheminer le nouveau trafic (7). La bande passante disponible sur le lien physique est alors diminuée par la même valeur. Si la bande passante demandée est supérieure à B disp sur l un des liens, l agent responsable de ce lien envoie un message à l agent d entrée de ce LSP l informant qu il est impossible d augmenter la capacité du LSP et la comparaison sera alors interrompue pour les liens suivants. En conséquence, l agent d entrée élimine la possibilité de re-dimensionner le LSP. S il y a suffisamment de bande passante permettant l établissement d un nouveau LSP, l agent d entrée vérifie la possibilité de créer un nouveau LSP sur un autre lien physique indiqué par le protocole de routage et en accord avec ses propres informations sur l état du réseau. Le LSP sera alors établi par le protocole de signalisation. Si aucun LSP n existe entre la paire de routeurs, le fonctionnement sera identique à celui où la bande passante demandée est supérieure à B disp. 4 Expérimentations et Résultats Nous considérons dans nos simulations, le protocole de signalisation le plus implémenté RSVP-TE [4] et le routage par contrainte. L algorithme de Dijkstra modifié (CSPF) est alors utilisé pour calculer le chemin explicite le plus court répondant à la contrainte de bande passante. Nous considérons également que les paquets arrivent au réseau labélisés avec une étiquette EF, AF, ou BE. Nous n entrons donc pas dans les détails de la classification effectuée par DiffServ. Nous supposons qu une seule requête arrive à chaque pas de simulation et qu il n est possible d établir qu un seul LSP par requête. Les nœuds source et destination sont aléatoirement choisis dans l ensemble des routeurs d extrémité. La demande de bande passante est uniformément distribuée entre 1 et 2 Mbits. Le nombre de requêtes varie de 5 à 8 sachant qu une requête pourrait consister en une demande de réservation ou de libération de bande passante. Chaque scénario est répété 1 fois et c est la moyenne des résultats obtenus qui est représentée dans les schémas. Nous avons évalué la performance de DATA en la comparant à la gestion classique (GC), celle d Internet. Le réseau considéré est présenté dans Fig. 3 et comporte sept routeurs d extrémité et trois routeurs intermédiaires. Les figures 4a et 4b montrent le nombre de LSP et le nombre d opérations de signalisation produites dans le réseau pour une bande passante maximale réservable de 5 Mbits/s. Nous remarquons qu en appliquant notre stratégie, le nombre de LSP et et le nombre d opérations de signalisation sont réduits d un facteur de 2. et 1.33 respectivement.

8 Fig. 3. Topologie considérée Nombre de LSP dans le réseau GC DATA (a) Nombre d opérations de signalisation GC DATA (b) Nombre de requêtes Nombre de requêtes Fig. 4. Nombre de LSP et d opérations de signalisation dans le réseau Nous avons fait varier la bande passante maximale réservable de 1 Mbits/s jusqu à 1 Mbits/s et avons calculé les facteurs de réduction obtenus lors de l utilisation d un SMA. Les figure 5a et 5b montrent le facteur de réduction du nombre de LSP et du nombre d opérations de signalisation respectivement. Notons que les facteurs de réduction sont plus importants pour les valeurs les plus élevées de la bande passante maximale réservable. Ceci s explique par le fait que lorsque la bande passante maximale réservable correspond à une valeur restrictive, seulement un faible nombre de LSP est créé dans les deux solutions (DATA et GC) causant, en conséquence, une petite différence entre les résultats des deux solutions. Cependant, lorsque la capacité correspond à une valeur élevée, un nombre plus élévé de LSP peut alors être créé. DATA propose de re-dimensionner les LSP existants au lieu d en créer de nouveaux causant ainsi une grande différence entre les résultats des deux solutions. Afin de vérifier les performances de DATA, nous avons calculé le taux de blocage. La figure 6 montre le taux de blocage dans les deux solutions pour une bande passante réservable de 5 Mbits/s. Les résultats obtenus montrent que DATA réduit le taux de blocage total, ce qui prouve l efficacité de DATA qui permet de diminuer le nombre de LSP et d opérations de signalisation dans le réseau tout en diminuant le taux de blocage.

9 Facteur de réduction du nombre total de LSP dans le réseau Bande passante maximale réservable (a) Facteur de réduction du nombre total d opérations de signalisation Bande passante maximale réservable (b) Fig. 5. Facteurs de réduction 1.9 GC DATA.8.7 Taux de blocage Nombre de requêtes Fig. 6. Taux de blocage 5 Conclusion et perspectives Dans ce papier, nous avons proposé DATA (Decentralized and Autonomous Traffic engineering management Approach), une nouvelle approche en ligne pour décentraliser et automatiser la gestion du réseau MPLS-DiffServ. DATA propose d introduire un SMA dans le réseau MPLS. En se basant sur l état du réseau, le SMA prend les décisions convenables et les applique au réseau. Le but de notre stratégie est de diminuer le nombre de LSP et le nombre d opérations de signalisation dans le réseau MPLS. Le défi est de déterminer quand créer un nouveau LSP et quand acheminer un nouveau trafic dans un LSP existant. Pour le faire, nous avons proposé une stratégie de gestion des LSP, basée sur une approche fondée sur le trafic et dépendant des conditions du réseau. Les résultats obtenus montrent que DATA peut réduire de manière importante le nombre de LSP ainsi que le nombre d opérations de signalisation tout en diminuant le taux de blocage de requêtes. Comme perspectives, nous prévoyons de définir de nouveaux cas d échanges d information entre les agents. Nous prévoyons également

10 de généraliser notre stratégie de gestion de LSP afin de rendre les capacités des trois réseaux virtuels dynamiques et gérées par le SMA. Références 1. N. Agoulmine and O. Cherkaoui. Pratique de la gestion de réseau. Eyrolles, Paris, G. Armitage. MPLS : The magic behind the myths. IEEE Communications Magazine, 38(1) : , P. Aukia, M. Kodialam, P. Koppol, T. Lakshman, H. Sarin, and B. Suter. RATES : A Server for MPLS Traffic Engineering. IEEE Network, 14 :34 41, March /April D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, and G. Swallow. RSVP-TE : Extensions to RSVP for LSP Tunnels. RFC 329, December D. Awduche, J. Malcolm, J. Agogbua, M. O Dell, and J. McManus. Requirements for Traffic Engineering Over MPLS. RFC 272, September S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. An Architecture for Differentiated Service. RFC 2475, December R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin. Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification. RFC 225, September J. Ferber, O. Gutknecht, and F. Michel. From Agents to Organizations : An Organizational View of Multi-agent Systems. In AOSE, pages , M. S. Kodialam and T. V. Lakshman. Minimum Interference Routing with Applications to MPLS Traffic Engineering. In IEEE INFOCOM (2), pages , E. Mykoniati, C. Charalampous, P. Georgatsos, T. Damilatis, D. Goderis, P. Trimintzios, G. Pavlou, and D. Griffin. Admission control for providing QoS in Diff- Serv IP networks : the TEQUILA approach. IEEE Communications Magazine, 41(1) :38 46, R. Rahim-Amoud, L. Merghem-Boulahia, D. Gaiti, and G. Pujolle. An Autonomic MPLS DiffServ-TE Domain. Whitestein Series in Software Agent Technologies and Autonomic Computing, 27. To appear. 12. E. Rosen, A. Viswanathan, and R. Callon. Multiprotocol Label Switching Architecture. RFC 331, January C. Scoglio, T. Anjali, J. de Oliveira, I. Akyildiz, and G. Uhl. TEAM : A Traffic Engineering Automated Manager for DiffServ-Based MPLS Networks. IEEE communications magazine, 42(1) : , October X. Xiao, A. Hannan, B. Bailey, and L. Ni. Traffic engineering with MPLS in the Internet. IEEE Network Magazine, pages 28 33, March 2.