Gestion de la Qualité de Services par les Règles de Politiques dans IP au dessus de

Transcription

1 SETIT th International Conference: Sciences of Electronic, Technologies of Information and Telecommunications March 22-26, 2009 TUNISIA Gestion de la Qualité de Services par les Règles de Politiques dans IP au dessus de Oumarou HALIDOU et Radouane MRABET Université Mohammed V - Souissi Ecole Nationale Supérieure d informatique et d Analyse des Systèmes BP 713 Agdal, Rabat, Maroc oumarhalid@yahoo.fr mrabet@ensias.ma Résumé: Dans cet article nous nous intéressons au standard IEEE , la dernière avancée technologique dans le monde des réseaux sans fil. Cette technologie permet de fournir des bandes passantes élevées avec une garantie de la qualité de services (QdS) au sein de la cellule. Afin de garantir la QdS de bout en bout à travers Internet nous proposons une plateforme basée sur la gestion des réseaux par politiques (PBNM). Plateforme permettra un déploiement de la QdS aussi bien au niveau de la cellule qu au niveau IP. Pour atteindre notre objectif, nous avons défini des règles de mapping pour l interfaçage des deux couches, et les mécanismes d ordonnancement des différentes classes de service. Mots clés: , DiffServ, IntServ, QdS de bout en bout, PBMN, PDP, PEP, ordonnancement 1. Introduction La globalisation des technologies Internet et des communications mobiles ainsi que la convergence de ces deux mondes, suscitent un très grand intérêt pour les chercheurs et les industriels et ouvre des possibilités énormes devant les utilisateurs. On s achemine vers une nouvelle génération de réseaux appelé NGN (Next Generation Networks). Afin de s adapter aux grandes tendances qui sont la recherche de souplesse d évolution de réseau, la distribution de l intelligence dans le réseau, et l ouverture à des services tiers, les NGN sont basés sur une évolution progressive vers le «tout IP» et sont modélisés en couches indépendantes dialoguant via des interfaces ouvertes et normalisées. Dans ce contexte, il devient dangereux, voir impossible pour de grands réseaux, de configurer manuellement l ensemble des équipements du réseau à cause de l abondance des informations dont il faut tenir compte et surtout de leur nature dynamique. Le recours à des outils de gestion autonomes et dynamiques se révèle donc indispensable. C est dans cette optique que fut créée la gestion par politiques, couramment appelée PBNM (Policy-Based Network Management). Le groupe RAP (Ressource Allocation Protocol) de l IETF est à l origine de l architecture utilisée de nos jours pour la gestion par politiques [Yav 00]. Elle repose sur un serveur de règles qui interprète et combine des informations enregistrées dans des bases de données circonstancielles pour prendre une décision quant à la politique à adopter ; les directives sont envoyées aux noeuds du réseau dans un second temps. L intérêt est de permettre la mise en place en temps réel de services supportant par exemple de nouvelles normes de la qualité de service (QdS) ou de sécurité. Dans ce papier, nous nous intéressons à la gestion qualité de service dans un contexte IP avec le standard comme réseaux d accès. Nous proposons une architecture basée sur les PBNM pour la gestion du réseau. Dans la section 2 nous rappelons les propositions de l IETF pour l intégration de QdS dans IP. La section 3 sera consacrée aux mécanismes de QdS dans le standard La section 4 sera consacrée à la présentation de notre architecture. Nous terminerons par une conclusion suivit de quelques perspectives 2. Modèle de QdS dans IP Le réseau Internet, a été basé initialement sur le principe du Best Effort. Le modèle Best Effort assure la connectivité sans aucune garantie de la qualité de - 1 -

2 service (QoS). Quand la mémoire d un routeur est saturée, les paquets arrivant sont rejetés. Les mécanismes de retransmission de TCP recouvrent ces pertes, garantissant un transfert sans faute de bout en bout. Bien que le comportement de TCP répond aux besoins d applications traditionnellement majoritaires dans le réseau comme telnet ou ftp, il est peu adapté pour la transmission des flux avec des contraintes temporelle (applications de visioconférence ou de Voix sur IP (VoIP). La discipline de service FIFO n est plus suffisante pour satisfaire les contraintes requises par les différentes applications. Les congestions allongent les délais, génèrent de la gigue et provoquent la perte des paquets. Pour répondre à ces demandes d amélioration de la QdS dans l Internet, l IETF définit de approche : IntServ et DiffServ. L approche IntServ (Integrated services) représente la première tentative par l IETFh pour améliorer la QdS dans Internet [Bra 94]. La caractérisation principale de IntServ est de garantir les niveaux de QdS par un mécanisme de réservation de ressources par flux. IntServ inclut deux types de services qui ciblent le trafic temps réel : service garanti et service prédictif. Ils fonctionnent correctement en unicast et multicast. Ces services, implémentés au sein des routeurs, devraient allouer aux flots une certaine qualité de service, à chaque traversée des routeurs, pour les acheminer jusqu à destination avec cette QdS. Il est donc nécessaire de disposer de mécanismes de réservation de ressources pour obtenir ces services. Pour cela, l émetteur envoie une requête de réservation de bande passante qui doit être acceptée par l ensemble des équipements qui seront traversés par les flux. La réservation s effectue au moyen du protocole RSVP [Bra 97]. Cependant, cette solution s est avérée insuffisante pour des réseaux à large dimensionnement. IntServ n est pas propice à des réseaux de grande envergure. C est pourquoi un second groupe de travail a abordé le problème en proposant une garantie se service basée sur la différenciation de service. Le groupe DiffServ (Differentiated Services) fonde son concept sur une gestion de trafic par classe, sur des méthodes de conditionnement du trafic à l entrée du réseau et sur le marquage de celui-ci en fonction de son appartenance à une classe, pour un traitement spécifique [Bla 98]. Trois principaux services de DiffServ sont mis en oeuvre : le service «Best-Effort» pour les paquets à traiter «au-mieux» comme le fait Internet actuellement ; le service «Assured Forwarding» [Hei 99] pour des classes à priorité plus grande que le «Best-Effort» ; enfin le service «Expedited Forwarding» [Dav 02] pour les classes les plus prioritaires. 3. Mécanisme de la QdS dans Le Standard commercialement appelé WiMAX (Worldwide Interoperability for Microwave Access), a été adopté comme la solution aux réseaux sans fils large bande (Broadband Wireless Access) [Air 04]. Il permet des connexions sans-fil à haut débit sur des zones de couverture de plusieurs kilomètres, permettant des usages en situation fixe ou en mobilité. Cette technologie permet de fournir des hauts débits et une QdS implantée dans le standard dès sa conception. Divers mécanismes ont été introduits dans pour l approvisionnement et la gestion de la QdS. Dans les paragraphes suivantes nous allons décrire les mécanismes implémentés au niveau de la couche MAC à savoir la notion de service flow et la demande et l allocation de la bande passante Service flow Le principal mécanisme pour fournir la qualité de service est le fait d associer un paquet de données à un flux de service (service flow). Le flux de service est une notion capitale dans le standard. Chaque connexion est liée à un SFID (Service Flow IDentifier) qui identifie les spécificités du flux de données en termes de besoins en QdS. WiMAX supporte cinq types de flux de service : Unsolicited Grant Service (UGS) : Ce type de service est utilisé pour supporter des flux temps réel générant des paquets de taille fixe et de façon périodique comme VoIP (Voice over IP). Il offre une garantie stricte du débit et du temps de latence. Extended rtps : c est une combinaison entre UGS et rtps. A la différence d UGS, la taille des paquets peut être modifiée durant la vie d une connexion suite à une requête émise par une SS real time Polling Service (rtps): Service supportant des paquets de données de tailles variables. Ce sont en général des flux multimédia comme la vidéo MPEG. Il offre des garanties pour le débit avec une grande tolérance vis-à-vis du temps de latence. non real time Polling Service (nrtps): Ce service garantit seulement le débit, il est destiné pour des applications ne dépendant pas du temps de latence (comme par exemple les s). C est le service qui supporte des profiles de burst très variés. Best Effort Service (BES) : Ce service ne donne pas de garantie, mais offre toutes les possibilités pour n importe quelle application. Il est surtout destiné pour des applications comme l accès au Web 3.2. Demande et allocation de la bande passante A chaque connexion, la station de base demande de la bande passante à travers un message MAC dit «Bandwidth Request message». Cette demande peut - 2 -

3 être envoyée soit dans un paquet autonome ou dans un paquet de données (piggyback). La requête est basée sur le nombre d octets nécessaires pour transporter les MAC PDUs sans compter la surcharge de la couche physique. La demande peut être soit incrémentale signifiant combien de bande passante additionnelle a-t-on besoin ou agrégée signifiant combien de bande passante totale a-t-on besoin. Avec la demande piggyback, la connexion ne peut faire qu une demande incrémentale alors que les deux sortes de demandes à savoir incrémentale et agrégée sont acceptées par une demande autonome. L allocation de la bande passante est strictement dépendante des paramètres QdS demandés et des ressources disponibles dans le réseau. Bien que la demande est faite par connexion, la BS répond en allouant la bande passante non pas par connexion mais par SS. La tâche revient à la SS de répartir cette bande passante entre ses différentes connexions. WiMAX définit trois principales procédures d allocation de bande passante : «unsolicited bandwidth grants» ou allocation de bande non réclamée, «polling» ou allocation de bande par système d interrogation des SSs, «contention procedures» ou allocation de bande selon un système de contention. L utilisation de ces procédures se fera en fonction des données devant être transmises, pour les applications temps réel par exemple, la station de base envoie un message de polling à chaque station et ces dernières répondent par les messages de requête de bande passante. 4. Architecture IP au dessus de Un des atouts majeurs d IEEE par rapport à son prédécesseur IEEE (Wifi) est le fait d intégrer la notion de la QdS dès sa conception. Mais l approvisionnement de QdS dans le standard se limite seulement au niveau des connexions entre la BS et les différentes SS qui lui sont attaché. Dans un contexte de déploiement général de WIMAX, on retrouvera des architectures ou les BS sont interconnectées via l Internet «Best Effort» (figure 1). Figure 1: cellules interconnectées via Internet Ainsi pour avoir une QdS de bout en bout il faudra développer des mécanismes supplémentaires pour l interconnexion de cellules à travers IP. Nous proposons une architecture fonctionnelle à QdS multicouches ( la couche et IP) présentée à la figure 2. Cette architecture est basée sur les modèles IntServ et DiffServ. Nous considérons que les BS jouent le rôle de routeur de bordure. Nous avons défini deux blocs fonctionnels : le SPM (Service Provider Module) et le RCM (Resources Control Module). Par ailleurs, on a défini des règles de mapping entre les services et paramètres des différentes couches. Figure 2: architecture générale 4.1. SPM (Service Provider Module) Le SPM assure plusieurs fonctions dans notre architecture. Il est responsable du contrôle et de la gestion de toutes les ressources du domaine. Le SPM intègre les fonctionnalités d un PDP (Policy Decision Point). Au départ, il choisit les règles de politique qu il appliquera à un utilisateur en considérant les informations du SLA-SLS négocié avec l utilisateur. Ces décisions sont ensuite envoyées d une manière asynchrone vers les RCM via le protocole COPS [Dur 00] pour réaliser la configuration décidée. Le SPM effectue un calcul de probabilité en fonction de tous les SLA-SLS des clients abonnés puis envoie l information de configuration au RCM, telle que le changement de politique demandé directement par l utilisateur en modifiant son abonnement, à une heure prédéterminée, à l expiration d un compte, etc. Le RCM confirme que l installation de configuration est réussie à la suite du message de configuration. Le SPM est en quelque sorte un organe de décision qui recherche les informations dont il a besoin dans de nombreux serveurs qui communiquent directement avec lui de façon à prendre une décision. Ces serveurs peuvent être locaux, ce qui est le cas le plus général, mais ils peuvent aussi être distants. Les serveurs les plus couramment utilisé sont : La base de données des politiques (Policy Repository) est en charge du stockage des - 3 -

4 règles de QdS (ou autre ). L IETF préconise l utilisation d annuaires pour implémenter le Policy Repository et celle du protocole LDAP (Lightweight Directory Access Protocol) pour y accéder. Le gestionnaire de bande passante (Bandwidth Broker) connaît la topologie et les caractéristiques du réseau ce qui lui permet de distribuer les ressources à bon escient. Le gestionnaire de sécurité (Security Brocker) est généralement un serveur AAA (Authentification, Autorisation and Accounting). Le serveur de mobilité (Mobility Brocker) peut gérer la continuité du service (comme la QdS) pendant un déplacement. Le serveur de facturation sera essentiel lorsque les réseaux feront de la QdS car sans différenciation tarifaire entre les CoS (Class of Service) il est impossible de mettre en place une quelconque qualité de service RCM, Resources Control Module Le RCM est le composant central de notre architecture. Il doit être présent dans tous les routeurs de bordure. Il peut être vu comme une couche intermédiaire entre la sous-couche «Service Specific Convergence Sublayer» de la couche et DiffServ ou IntServ, dans le sens où c est lui qui effectue le mapping des paramètres QdS entre les deux niveaux. Il intègre aussi le module AM (Authorization Module) qui s occupe localement du contrôle de politique et du contrôle d admission sur la base des ressources qu il s est vu allouer par le SPM. Le RCM intègre en même temps les fonctionnalités d un PDP et d un PEP. Vu par le SPM, le RCM est une PEP munie d un LPDP. L intérêt est que le RCM pourra prendre lui-même une première décision dans certaines circonstances pour appliquer une décision locale (perte de la connexion entre le RCM et le SPM, attente de décision trop longue, ) mais le SPM conserve dans tous les cas son autorité. Ce qui veut dire qu'une décision locale doit être transmise au SPM dès que possible par un objet de décision LPDP que le serveur de règles confirmera ou remplacera. Ainsi lorsqu une application demande un service avec QdS, le RCM interroge d abord son PDP local. Après avoir récupérer la réponse de celui-ci, deux possibilités peuvent se présenter : Soit le SPM est injoignable à cause d une panne. Le RCM applique alors cette décision. Soit le réseau fonctionne correctement. Dans ce cas, le RCM envoie au SPM la décision de local PDP accompagnée de la question d origine. Le SPM prend en compte cette décision et d autres informations globales puis retourne la décision finale prévalant sur celle du local PDP se trouvant dans le RCM. L intérêt de ce mécanisme est double : En temps normal, on peut imaginer que le RCM dispose d informations locales inaccessibles au SPM. C est pourquoi le SPM doit tenir compte de la décision du local PDP du RCM même s il n est pas tenu de la suivre. Lorsque le RCM ne peut plus joindre le SPM, son local PDP lui permet de continuer à fonctionner de façon autonome au moins pendant un certain temps. Cela suppose cependant que les politiques que le local PDP a en mémoire sont à jour par rapport à celles du SPM. Aussi, le RCM gère la souscription et la négociation des SLA (Service Level Agreement) entre le domaine réseaux et les utilisateurs ou entre domaines. Pour ce faire nous utilisons le protocole COPS-SLS [Tra 03]. En effet, COPS-SLS est une extension du protocole COPS qui a été développée pour la négociation dynamique de SLS intra et inter domaine. COPS-SLS permet, en particulier, d échanger des paramètres techniques caractérisant un niveau de service (i.e. Service Level Specification) entre un client et un réseau ou entre deux réseaux entre eux. COPS-SLS est le premier protocole qui propose de mettre le PEP dans un équipement terminal. Dans les extensions indiquées précédemment, le PEP était mis dans les équipements réseaux avec pour but de gérer les routeurs du réseau (routeurs de bord, routeurs coeur ). Dans le contexte d une négociation de SLS, mettre le PEP dans l équipement terminal est une solution originale permettant d introduire la meilleure politique correspondant à chaque type de client ou même à chaque client. L'intérêt de ce protocole concerne d une part la négociation du SLS par une automatisation du processus : le client peut facilement gérer son SLS en entrant en contact avec le RCM sur lequel il est connecté. COPS-SLS peut également gérer dynamiquement les modifications de SLS lors du déplacement du client pour lui assurer une continuité dans sa QdS. L'idée de COPS-SLS est d'appliquer la technologie de gestion par politique pour la gestion des niveaux de service dans un domaine. Le SPM crée des politiques de négociation de SLS du domaine. Ces politiques reflètent la stratégie de négociation du SPM et permettent au PDP de savoir comment répondre à une demande de SLS ou de modification du SLS

5 4.3. Règles de mapping entre services Après une étude comparative des différentes classes de services DiffServ, IntServ et WiMAX, nous constatons que les classes EF de DiffServ, Guaranted de Intserv et UGS du ont les mêmes caractéristiques. Elles ont pour but de fournir une garantie de bande passante avec des taux de perte, délai et gigue faibles. Elles sont destinées aux applications temps réel comme la téléphonie sur IP. Les services rtps, ertps et nrtps ont aussi des caractéristiques similaires à la famille AF DiffServ et Controlled Load de IntServ. les Best Effort (BE) seront associées entre elles. Le tableau ci-dessus présente ces différentes règles. Classe Intserv Classe DiffServ Classe WiMAX Figure 3: Ordonnancement dans DiffServ Guaranted EF UGS Controlled Load AF rtps,ertps, nrtps BE BE BE Tableau1: Correspondance entre les classes de services 4.4. Schémas d ordonnancement Dans l architecture DiffServ, le traitement différencié des paquets s appuie sur trois opérations fondamentales : la classification des flux en classes de service, l introduction de priorités au sein des classes (Scheduling) et la gestion du trafic dans une classe donnée (Queue Management). La deuxième opération est assurée par les algorithmes d ordonnancement, servant à contrôler la distribution de ressources entre les classes de service. Dans ce travail, nous utilisons deux types d Ordonnanceurs : PQ (Priority Queueing) et WFQ (Weighted Fair Queuing). L algorithme d ordonnancement basé sur des priorités strictes (PQ) peut être utilisé pour offrir un très faible délai pour la classe la plus prioritaire, ce qui est désirable pour des applications à contraintes temps réel très sensibles aux délais telles la voix sur IP. Nous attribuons la priorité absolue aux paquets EF et UGS. Dans l algorithme d ordonnancement WFQ on associe à chacune des classes de service un poids positif. Ce poids spécifie la capacité minimum garantie pour la classe. En particulier, si une classe n utilise pas la totalité de sa capacité, alors l excès de capacité est distribué aux autres classes. Figure 4: Ordonnancement dans le standard Ainsi, comme illustré sur la figure 3 et 4, dans un premier niveau les paquets des classes AF et BE sont classifiés dans une fille d attente à l aide de l algorithme WFQ, idem pour ceux des services rtps, nrtps et BE de WiMAX. Au deuxième niveau nous appliquons une politique PQ entre la file issue de l ordonnanceur WFQ et la fille de la classe EF dans DiffServ ou UGS au niveau de WiMAX. Nous appliquons les memes principes pour les classes de services Intserv. 5. Conclusion Dans cet article, nous avons présenté une architecture basé sur le standard garantissant une qualité de service de bout en bout à travers Internet. Dans un premier temps, nous avons mis en évidence les divers mécanismes de gestion de la QdS dans les différentes couches, montrant ainsi les limites de la gestion de la QdS au niveau des cellules du standard Ainsi pour fournir aux stations mobiles (MS) une QdS de bout en bout nous avons décidé de coupler le standard avec les modèle d architecture définit par IETF pour l approvisionnement de la QdS. Cette prise en charge de la QdS aux niveaux des deux couches permettra un déploiement à grande échelle des services à fortes contraintes de QdS à travers Internet. Pour automatiser la gestion d une telle architecture - 5 -

6 et le processus de négociation des contrats de services nous utilisons les règles de politiques avec les le protocole COPS et son extension COPS-SLS. Chaque couche ayant ces propres spécificités et contraintes, nous avons définit des règles de mapping pour le passage du trafic dans les deux. Aussi nous avons choisi les algorithmes d ordonnancement adéquats pour garantir la différenciation des services REFERENCES [Yav 00] R. Yavatkar, D Pendarakis :A Framework for Policy-based Admission Control RFC 2753, January 2000 [Bra 94] R. Braden, D. Clark, S. Shenker,: Integrated Services in the Internet Architecture: an overview, RFC 1633, Juin 94. [Bra 97] R. Braden, et al : Resource ReSerVation Protocol (RSVP), RFC 2205, Septembre [Bla 98] S. Black et al: An Architecture for Differentiated Services, RFC 2475, Déc [Hei 99] J. Heinanen et al : PHB, RFC 2597, Juin Assured Forwarding [Dav 02] B. Davie et al : An Expedited Forwarding PHB (Per-Hop Behaviour), RFC 3246, Mars [Air 04] Air Interface for Fixed Broadband Wireless Access Systems, IEEE Standard ; [Nic 99] K. Nichols et al., «Two-bit Differentiated Services Architecture», RFC 2638, Juillet [Tra 03] Trang Nguyen TM, Boukhatem N.; Doudane, Y.G.; Pujolle, G. COPS-SLS usage for dynamic policy-based QoS management over heterogeneous IP networks. IEEE Communications Magazine, Vol. 17, n 3, May-June [Dur 00] The COPS (Common Open Policy Service) Protocol RFC 2748 D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry Janvier