Architecture de bout en bout à QdS garantie dans un environnement DiffServ multi domaines : protocoles de signalisation

Transcription

1 Architecture de bout en bout à QdS garantie dans un environnement DiffServ multi domaines : protocoles de signalisation End to end architecture managing QoS in a multi-domain DiffServ environment: signalling protocols Guillaume AURIOL 1 doctorant encadré par Christophe CHASSOT 1 1 LAAS-CNRS LAAS-CNRS, 7 avenue du Colonel Roche, Toulouse Cedex 04, France gauriol@laas.fr Résumé Les travaux de recherche décrits dans cet article portent sur la définition de protocoles de signalisation déployés dans un environnement DiffServ multi domaines. Ces protocoles s intègrent dans une architecture de communication permettant d offrir aux utilisateurs des garanties de QdS de bout en bout. L article présente tout d abord les principes d une première architecture adaptée à un environnement mono-domaine, puis décrit la nouvelle architecture des protocoles prenant en compte le contexte multi-domaines ainsi que leur déploiement. Mots Clef Architecture, DiffServ multi-domaines, QdS. Abstract Research reported here deals with the definition of signalling protocols over a multi DiffServ environment. These protocols, associated with an appropriated architecture of communication, offer to the users end to end QoS guaranties. First, this paper presents principles of a previous architecture deployed over a mono domain environment, then, it presents the extension of this architecture to take in consideration the multi domain environment and finally, the last part depicts the protocol deployment. Keywords Architecture, QoS, DiffServ, multi-domain abouties mais sont déployées sur un seul domaine ou Autonomous System (AS), ce qui permet une maîtrise relativement aisée des politiques de gestion de la QdS. Or les communications peuvent impliquer plusieurs domaines ayant chacun une politique propre de gestion de la QdS. Une des préoccupations actuelles est donc de proposer des architectures [14, 15, 16] qui sont capables de s adapter à un environnement multi-domaines. Les travaux présentés dans cet article s inscrivent dans ce contexte et portent sur la conception d une architecture de protocoles de signalisation déployés en des points spécifiques des différents domaines DiffServ. Ces protocoles ont pour cadre une architecture de communication permettant de gérer de bout en bout la QdS, de façon transparente pour un utilisateur (i.e. un programmeur d application) au travers des différents domaines rencontrés. L objectif ciblé par notre architecture est de satisfaire les besoins applicatifs (exprimés en terme de paramètres de QdS) au moyen des services des couches Transport et Réseau minimisant l utilis ation des ressources du réseau. Le paragraphe 2 présente les principes de l architecture de communication avec son déploiement dans un contexte mono-domaine DiffServ, ainsi que les principes des mécanismes de gestion automatique de la QdS basés sur la caractérisation des services IP [9]. Le paragraphe 3 détaille les protocoles de signalisation déployés pour offrir les mêmes garanties de QdS mais dans un environnement multi domaines. Les conclusions et perspectives de ces travaux sont décrites au paragraphe 4. 1 Introduction Depuis quelques années de nombreux travaux ont permis de proposer des architectures de communication à QdS [4], [11], [13]. Ces architectures de communications s appuient sur l approche soutenue par le Working Group DiffServ [2], solution basée sur l application de différents comportements des routeurs (ou PHB Per Hop Behavior) en fonction du marquage des paquets. Ces solutions sont

2 2 Architecture de communication dans un contexte DiffServ mono-domaine 2.1 Principes de l architecture Le principe de base qui sous-tend la proposition d architecture de bout en bout du 1 est celui de plusieurs autres architectures dédiées au transport de flux multimédias [4, 11, 5]. L idée est que le trafic échangé dans le cadre d une application distribuée peut être décomposé en plusieurs flux de données, requérant chacun une QdS spécifique (exprimable en termes de délai, de fiabilité, ). Sur ces bases, les principes de l architecture de bout en bout du sont les suivants. Au travers d une session (voir Figure 1), le logiciel applicatif peut établir un ou plusieurs canaux de communication de bout en bout, chacun étant : (1) unicast, (2) dédié au transfert d un seul flux de données (i.e. monomédia), et (3) offrant une QdS spécifique au flux véhiculé. Pour cela, il dispose d une interface de programmation spécifique, l API (Application Programming Interface), offrant les paramètres et les primitives de service nécessaires. Système de communication de bout en bout Application Session 1 Session 2 Media 1 Media 2 Media 3 API Vérification de la QdS : Egalité QdS Emetteur / QdS Récepteur Cohérence de la requête Protocole d acceptation / rejet de requête Protocole d établissement des canaux de beb (unicast, unidirectionnel, monomédia ) UDP / TCP / FPTP BE / AS / GS Figure 1 : Architecture du système de communication de bout en bout Outre l API, le système de communication intègre trois modules. Le premier, lié à l API, va prendre en compte tous les mécanismes liés à la gestion de la QdS dont le principe est donné dans la section suivante. Le deuxième module donne accès à plusieurs services Transport, tels que : une garantie totale sur l ordre et la fiabilité (fournie par le protocole TCP), 1 Le (Architecture Intégrée de Réseaux et Services - Décembre Avril 2001) est un projet français du Réseau National de la Recherche en Télécommunications (RNRT), visant à développer et analyser de nouveaux mécanismes et protocoles pour l Internet (Ipv6 et QdS notamment) dans un environnement de réseaux hétérogènes. IPv4 une garantie de fiabilité et d ordre partiel intra flux et/ou inter flux (fournie par le protocole FPTP 2 issu des travaux de [8]), aucune garantie d ordre ni de fiabilité (fournie par le protocole UDP). Le dernier module donne accès aux services IP : le service BE (Best Effort) n offre aucune garantie de QdS ; le service garanti GS (Guaranteed Service) 3, analogue au service Premium [3], a été retenu pour les flux applicatifs à fortes contraintes de temps et de fiabilité. Les applications ciblées par ce service sont celles ne tolérant pas de variation de QdS ; le service assuré AS (Assured Service) a été retenu pour répondre au besoin des flux réactifs n ayant pas de trop fortes contraintes de délai, mais requérant une bande passante minimale. Un flux servi en AS dispose d une bande passante minimale garantie pour la partie de son trafic respectant la caractérisation de trafic formulée pour le flux considéré. La partie de son trafic excédant la caractérisation est véhiculée en AS tant qu aucune congestion n intervient sur le chemin emprunté par le flux. Les primitives et paramètres de l API permettent aux applications de caractériser leurs requêtes avec comme paramètres de QdS : un ordre partiel intra flux permettant d exprimer des contraintes de synchronisation intra flux, un ordre partiel inter flux, permettant à l application d exprimer des contraintes de synchronisation logiques entre des flux différents ; une fiabilité partielle et un délai de transit, exprimés en termes de : pourcentage (%) des paquets émis que l application souhaite recevoir : τ r, % des paquets émis que l application souhaite recevoir dans l intervalle de temps ]0,b] : (τ d, ]0,b]). L application peut coupler chacun des paramètres précédents à une des sémantiques de garantie suivante : une garantie absolue, notée A, qui précise que le système de communication devra obligatoirement respecter la valeur du paramètre, une garantie en moyenne, notée M, qui donne la possibilité au système de communication de dévier de la valeur nominale du paramètre. 2.2 Mécanismes de gestion de la QdS Ce paragraphe présente les mécanismes de gestion de la QdS qui permettent d offrir des garanties de QdS aux utilisateurs sans qu ils aient à connaître dans les détails les protocoles de Transport et les services IP Principe des mécanismes 2 Fully Programmable Transport Protocol 3 Les auteurs ont conscience du fait que la dénomination adoptée pour ce service peut prêter à confusion vis à vis du Guaranteed Service défini par IntServ. Le service n est cependant pas le même.

3 Le principe des mécanismes de gestion automatique de la QdS repose sur la sélection de l un des trois services IP et du protocole de Transport adéquats pour satisfaire une requête de l application formulée selon les paramètres et les sémantiques de garantie de QdS précédemment définis. L application précise simplement via une primitive de notre API, l adresse de son correspondant et l ensemble de ses paramètres de services et le système de communication lui retourne, si c est possible les services IP et Transport sélectionnés. Pour pouvoir opérer cette sélection des services, le système de communication connaît la caractérisation (i.e. les performances) des services IP entre la source et la destination et, au regard de cette caractérisation et de la requête de l application ; il peut répondre à l application soit en lui retournant le service IP et protocole de Transport adaptés soit en lui signalant que la communication est impossible Caractérisation des services Deux campagnes de mesure ont été réalisées sur la plateforme [6], voir figure 2, afin d étudier les possibilités de caractériser les services IP (nous rappelons qu il n existe pas dans l approche DiffServ de caractérisation des services, mais qu il est défini seulement des PHB). E1 E2 LAAS-CNRS Toulouse Rb Rc Rc Rb R LIP6 Paris Figure 2 : Topologie de la Cette plate-forme comprenait simplement deux émetteurs (E1 et E2), un récepteur (R) et qu un nombre limité de routeur de bordure (Rb) et de cœur (Rc). La première campagne avait pour objectif d évaluer la QdS fournie à un flux UDP de charge variable, servi en AS (resp. GS), en présence d un flux BE dont la charge allait en s accroissant jusqu à saturation complète du réseau. La seconde campagne a permis d évaluer l impact que pourrait avoir la présence simultanée de plusieurs flux à QdS chacun ayant des caractéristiques (en termes de charge et/ou de marque) différentes. Les résultats de ces mesures [6] ont permis de conclure que les QdS AS et GS étaient conformes à celles attendues, à savoir un impact nul du trafic BE sur la QdS GS et «acceptable» sur la QdS AS et que pour une charge donnée du réseau une différence de charge (entre les flux AS) ou de marque a un impact faible sur les performances des flux AS. Ce résultat est la base de la caractérisation des services en permettant de poser comme hypothèse qu il est possible de caractériser statistiquement les performances du service AS par la fonction de répartition du délai de bout en bout des paquets d un flux servi dans cette classe (et par extension nous avons le même résultat pour les service GS) pour une route donnée et en considérant un état de charge du réseau donné. La fonction de répartition des délais de transit des paquets d un flux F(t) représente alors le taux de paquets qui sont reçus ayant un délai de transit inférieur à t. Des campagnes de simulation [1] ont permis d étendre la validité de ces résultats dans une configuration plus large, en augmentant : (1) le nombre d émetteurs par site local, (2) le nombre de sites locaux convergeant sur un routeur de cœur et (3) le nombre de routeurs de cœur, chacun étant chargé par un site local Caractérisation des services : cas du multidomaines La valeur des délais de transit des paquets d un flux donné peut être considérée comme une variable aléatoire prenant ses valeurs dans un intervalle [t min, [ avec t min le plus petit délai observable et dans le cas où le paquet est perdu. Lorsque les paquets d une communication traversent deux domaines caractérisés par des fonctions de répartition des délais (entre un point d entrée et un point de sortie du domaine considéré, pour un état de charge du réseau donnée) F X et F Y, en supposant que les deux variables aléatoires X et Y, représentant le délai de transit dans le premier domaine et le second domaine, sont indépendantes en probabilité, la fonction de répartition F Z des délais de bout en bout des paquets, avec Z = X+Y, est définie par : d F t = F t F t où * est l opérateur de Z ( ) ( ( ) ( )) X Y dt convolution pour l algèbre (+, ). Ce résultat se généralise facilement à un environnement de n domaines grâce aux propriétés mathématiques de la convolution. Il nous permettra alors de déduire, de l ensemble des caractérisations des services sur les différents domaines, les caractéristiques du service de bout en bout résultant et il est intégré par la suite dans les mécanismes de sélection des services en environnement multi-domaines. 3 Extension de l architecture au contexte du multi domaines Ce paragraphe expose les extensions de l architecture de signalisation mono-domaine que nous proposons pour adresser les problèmes liés à un contexte multi-domaines. Les différents protocoles de notre nouvelle architecture sont également détaillés. Nous introduisons tout d abord ces nouveaux problèmes en situant dans le même temps notre contribution vis à vis de certaines solutions actuellement proposées. Rappelons ici que notre objectif est de développer une architecture de maîtrise de la QdS dans un environnement IP multi-domaines permettant : de sélectionner le service de Transport à mettre en œuvre de bout en bout ainsi que le service de niveau IP à requérir au sein chaque domaine de la route reliant les

4 hôtes émetteur et récepteur de sorte à satisfaire la QdS requise par l application pour chacun de ses flux ; de mettre en place les réservations de ressources correspondant aux services IP sélectionnés au sein des différents domaines. 3.1 Problèmes liés à un contexte multi domaines Concernant la maîtrise de la QoS, plusieurs problèmes résultent de la structuration de l Internet en une interconnexion domaines déployant chacun des PHB potentiellement différents. Les conséquences de cette hétérogénéité se traduisent par plusieurs problèmes non indépendants : 1) la difficulté de caractériser le service IP de bout en bout résultant de l application de différents PHB successifs (un par domaine traversé). Tel qu exposé au paragraphe (2.2.3) Notre contribution s attache en particulier à ce problème. 2) l absence d homogénéité dans la définition des services. Dans le cas du mono-domaine, la définition des services offerts aux clients est précisée dans le SLA (Service Level Agreement). Dans le cas du multi domaines, chaque administrateur peut mettre en place des services qu il caractérise de façon «propriétaire». Afin de pouvoir caractériser le service de bout en bout, il apparaît donc nécessaire que les différents administrateurs adoptent une terminologie homogène. Cette volonté se traduit par exemple au travers du projet européen Eurescom EQUIP, dans lequel cinq opérateurs de télécommunications ont contribués à la proposition de définition et de caractérisation des services IP pour un environnement multi domaines. Notre proposition d architecture repose sur l hypothèse que chaque domaine est capable de caractériser les services IP offerts entre deux points d entrée quelconque (pour un état de charge donné) par un pourcentage de perte et une fonction de répartition des délais des paquets (voir paragraphe (2.2.2)). 3) La découverte des services IP disponible et de leur caractérisation. Dans le cas du mono-domaine, ce point ne présente pas de difficulté, les utilisateurs du domaine connaissant les services qui leur sont proposés. Dans un environnement multi-domaines, la connaissance des services tout au long de la route est plus difficile à obtenir. Pour cela, il faut mettre en œuvre des mécanismes qui permettent de découvrir les différents services rencontrés ainsi que leur caractéristiques, et de rapporter cette découverte aux utilisateurs d extrémité. A titre d exemple, l architecture développée dans [16], appelée NAIS (Network Architecture for Inter-domain Services), propose un ensemble de protocoles permettant de rassembler, en un point donné du réseau, les informations sur les services disponibles dans les différents domaines. Notre architecture répond également au problème de récupération des services disponibles le long de la route empruntée auxq uels elle ajoute la caractérisation des différents services. Elles distingue de NAIS par le fait qu elle inclut des mécanismes et protocoles d allocation de ressources le long de la route empruntée. 4) La gestion de l allocation des ressources. S il existe des solutions pour la réservation de ressource dans un environnement mono-domaine, l allocation dynamique de bout en bout des ressources de différents AS pose le problème de la négociation des ressources entre deux domaines voisins. Notre approche, également adoptée par [14,15,16], consiste à considérer qu il existe des composants spécifiques centralisant pour un domaine, la gestion des réservation des ressources pour l ensemble des requêtes. Ainsi, l architecture développée dans [15] repose sur l utilisation d un agent appelé BMP (Bandwidth Management Point) et utilise comme protocole de signalisation le protocole SIBBS (Simple Inter-domain Bandwidth Broker Signaling) qui permet d obtenir les ressources disponibles pour chaque route, ainsi qu une cartographie des routeurs de bordure de chaque domaine. Elle y ajoute un mécanisme de sécurité pour authentifier les utilisateurs 3.2 Proposition d architecture pour le multi domaines L architecture que nous proposons repose sur l utilisation d équipements de type Bandwidth Brokers (BB) [12] implémentant chacun des mécanismes de gestion des ressources de leur domaine d appartenance (Figure 3). E D1 D2 Dn-1 Dn BB Rb1 Rb2 BB BB BB Figure 3 : Environnement multi-domaines En environnement mono-domaine, il nous était nécessaire de connaître la caractérisation des services IP disponibles entre routeur de bordure d entrée et de sortie (pour un état donné de charge du réseau) afin de pouvoir activer le mécanisme de sélection automatique des services IP et Transport. Pour l extension au multi-domaines, nous faisons l hypothèse que chaque BB a la connaissance de cette caractérisation pour toutes les routes définies entre deux points quelconques d entrée et de sortie de son domaine. Notons que dans la réalité, ces points d entrées et de sortie ne sont pas nombreux, quelques unités au plus. Sur ces bases, l architecture que nous proposons est composée de plusieurs protocoles permettant : de rapatrier sur le BB local au domaine de l hôte émetteur les caractéristiques et l état de disponibilité des services IP de chacun des domaines impliqués dans la route entre hôtes émetteur et récepteur ; de faire le choix du service de Transport à mettre en œuvre de bout en bout ainsi que des services IP à activer sur chacun des domaines, et de réserver la quantité de service IP adéquate sur chacun des BB ; de paramétrer le routeur de bordure (Rb1) du domaine d appartenance du hôte émetteur, de relâcher la réservation sur chacun des BB. R

5 Les détails des mécanismes de sélection automatique des services ne sont pas fournis dans cet article, mais ils sont fortement basés sur ceux employés en mono-domaine. Le paragraphe suivant détaille l architecture des protocoles sur les différents équipements Architecture des protocoles Quatre protocoles de signalisation composent l architecture : un protocole d établissement de la connexion entre l émetteur (E) et le récepteur (R). Il permet aux entités d application émettrice et réceptrice d échanger la QdS qu elles souhaitent voir appliquer pour un flux donné; un protocole de gestion de la QdS entre l émetteur et le BB local. Ce protocole permet à l émetteur de transmettre la requête de QdS à son BB ; un protocole de signalisation entre les BB. Il permet de propager la requête à tous les BB concernés ; un protocole de réservation de la QdS entre le routeur de bordure du site émetteur (Rb1) et le BB. Il permet au BB de donner les caractéristiques du nouveau flux au routeur de bordure pour qu il puisse appliquer les mécanismes définis dans le TCA. Les figures 4 et 5 représentent l architecture des protocoles dans les hôtes applicatifs et les BB. Application API Protocole d établissement de la connexion Transport (FPTP,TCP) IP DiffServ Figure 4 : Architecture au niveau des hôtes Protocole de gestion de la QdS Transport (FPTP,TCP) IP DiffServ Figure 5 : Architecture au niveau des BB Protocole de gestion de la QdS Protocole de signalisation 3.3 Mise en oeuvre des protocoles Le récepteur initie la communication par le biais du protocole d établissement de la connexion en envoyant les paramètres de la QdS qu il souhaite voir respecter pour le transfert d un flux donné. Sur réception de cette requête, l émetteur vérifie la cohérence de la QdS requise, puis se met en communication avec son BB local grâce au protocole de gestion de la QdS pour lui demander si la requête de QdS peut être satisfaite, et si oui via quels services IP et Transport. Pour répondre à cette question, le BB doit disposer de l ensemble des caractérisations des services IP disponibles dans les différents domaines de la route entre émetteur et récepteur. Pour cela, il consulte la table BGP (Border gateway Protocol) lui indiquant l adresse du prochain BB à contacter., puis par le biais du protocole de signalisation, envoie à ce prochain BB une requête de demande de caractérisation des services de son domaine ainsi que leur disponibilité. La requête de caractérisation et de disponibilité est propagée de BB en BB jusqu au dernier BB concerné (i.e. celui qui repère dans sa table de routage que le destinataire est directement accessible) ; en plus des caractéristiques de services IP de son domaine et de leur disponibilité, celui ci retourne également au premier BB un message indiquant qu il est le dernier BB. Ayant la connaissance de la caractérisation de l ensemble des services IP sur la route à emprunter, le premier BB peut alors mettre en œuvre les mécanismes de sélection des services (sur la base du résultat mathématique lié à la convolution évoqué dans le paragraphe (2.2.3)). Lorsque le premier BB trouve un couple protocole de Transport et service IP (la même classe de service IP est offerte sur tous les domaines) satisfaisant la requête de l application émettrice, il : (1) procède à la réservation effective du service IP sur chacun des BB, (2) informe le routeur de bordure du site émetteur des caractéristiques du nouveau flux et (3) retourne à l émetteur le service IP et protocole de Transport sélectionnés. Lorsque la communication est terminée, l application émettrice informe son BB pour que celui-ci puisse relâcher les ressources réservées. Conclusion et perspective Les travaux reportés dans cet article ont traité de la définition et du déploiement des protocoles de signalisation qui permettent de gérer de bout en bout la QdS au travers de plusieurs domaines DiffServ. Cette nouvelle architecture de communication à gestion automatique (car transparente pour l utilisateur) de la QdS s appuie : (1) sur les principes d une précédente architecture déployée dans un environnement IP monodomaine et (2) sur une caractérisation possible des services IP. Les principales perspectives de ces travaux concernent la réalisation d une plate forme de tests basée sur l utilisation d émulateurs pour reproduire le comportement d un domaine DiffServ afin de vérifier le bon fonctionnement de l ensemble des protocoles. Bibliographie [1] Auriol G., Chassot C., Diaz M. «Architecture de communication à gestion automatique de la QdS et validation en simulation ns-2» 10 ème CFIP'2003, Paris, 2003 [2] S. Blake, D. Black, M. Carlson, An Architecture for Differentiated Services, RFC [3] M. Campanella, T. Ferrari, S. Leinen, R. Sabatino, V. Reijs "Specification and implementation plan for a Premium IP service", [4] A. Campbell, G. Coulson, D. Hutchinson, A QoS architecture, ACM Computer Communication Review, [5] C. Chassot, A. Lozes, M. Diaz, From the partial order concept to partial order multimedia connection, JHSN, vol 5, n 2, 1996.

6 [6] Chassot C., Garcia F., Auriol G., Lozes A., Lochin E., Anelli P., «Performance Analysis for an IP Differentiated Services Network», ICC02, New York, USA, [7] [8] Exposito E., Senac P., Garduno D., et al., «Déploiement de nouveaux services pour le transport de flux multimédia», CFIP'2002, Montréal (Canada), 2002 [9] Chassot C., Auriol G., Diaz M., «Automatic management of the QoS within an architecture integrating new transport and IP services in a DiffServ internet», Lecture Notes in Computer Science 2839, Springer, 2003, pp [11] K. Nahrstedt, J. Smith, Design, Implementation and experiences of the OMEGA end-point architecture, IEEE JSAC, vol.14, [12] K. Nichols, V. Jacobson, L. Zhang, L, A Two-bit Differentiated Services Architecture for the Internet, [13] [14] A. Terzis, J. Ogawa, S. Tsui, L. Wang, L. Zhang «A prototype Implementation of the Two-Tier Architecture for Differentiated Services», 5th IEEE Real-Time Technology and App. Symp. (RTAS99) Vancouver, Canada, June 1999 [15] U. Hwang, R. Revuru «Inter-domain Diffserv dynamic provisioning and interconnection peering study using Bandwidth Management Point - A Simulation Evaluation», ISE 2003, Quebec, Canada, [16] P. Füzesi, K. Németh, N. Borg, R. Holmberg, I. Cselényi «Provisioning of QoS enabled inter-domain services» Computer Communications 26, page , 2003.