Conception d'un serveur de politiques (QoS) via le système MAUDE.

République Algérienne Démocratique et Populaire Ministère de l’Enseignement Supérieur

Et de la Recherche Scientifique Université de Constantine Faculté des Sciences de l’Ingénieur

Département Informatique N° d’ordre : Série : Thèse Présenté Par

ZEMMOUCHI Fares Mounir Pour l’Obtention du Diplôme de

Magister en Informatique

Conception d’un serveur de politiques (QoS) via

le système MAUDE

Devant le jury composé de :

M. CHAOUI Allaoua Maître de Conférence Président

M. ZAROUR Nacereddine Maître de Conférence Examinateur

M. CHIKHI Salim Maître de Conférence Examinateur

Mme BELALA Faiza Maître de Conférence Rapporteur

Laboratoire: LIRE, Université de Constantine. Équipe: Génie Logiciel et Systèmes Distribués

Remerciements

Je tiens à remercier toutes les personnes qui ont permis que cette année se passe de la meilleure façon qui soit. Plus précisément tous mes remerciements à Faiza BELALA responsable du bon déroulement de mon magister pour son encadrement efficace, ses idées inépuisables, sa disponibilité…. Et la patience dont elle a du faire preuve.

Je remercie aussi toutes les personnes qui de près ou de loin m'ont suivi pendant mon travail, notamment toute l'équipe LIRE, dans laquelle l'ambiance a toujours été au beau fixe, à ma famille.

TABLE DES MATIERES

2. LA QUALITE DE SERVICE DANS L’INTERNET...11

2.1. Introduction... 12

2.2. Gestion des flux ... 13

2.2.1. Intégration de service ... 13

2.2.2. Différenciation de services ... 15

2.2.3. Intégration IntServ / DiffServ ... 17

2.2.4. Ingénierie de trafic ... 17

2.3. Conclusion ... 19

3. LES SERVEURS DE POLITIQUES ...20

3.1. Introduction... 21

3.2. Définition d’une politique de QoS... 21

3.3. Structure et architecture d’une politique de QoS ... 22

3.3.1. Le PDP (policy décision point)... 23

3.3.2. Les PEP (Policy Enforcement Point) ... 23

3.4. Les langages de politique (Policy Language)... 24

3.4.1. Langage PFDL (Policy Framework Definition Language)... 25

3.4.2. Langage ProNet ... 26

3.4.3. Langage Ponder ... 26

3.5. Conclusion ... 32

4. LES ANNUAIRES LDAP ...33

4.1. Introduction... 34

4.2. Les concepts de LDAP... 35

4.2.1. Le protocole LDAP... 35

4.2.2. Modèles de données LDAP ... 36

4.2.3. LDIF ... 42

4.2.4. Le modèle fonctionnel... 44

4.2.5. Les URLs LDAP... 47

4.3. Exemples d'application de LDAP... 47

4.4. Déployer un service d’annuaire LDAP ... 48

4.4.2. Déterminer quelles données sont nécessaires ... 48

4.4.3. Choisir son schéma ... 49

4.4.4. Concevoir son espace (modèle) de nommage... 50

4.4.5. Le Directory Tree... 50

4.4.6. Nommage des entrées ... 51

4.4.7. Choix du suffixe ... 51

4.4.8. Définir la topologie de son service... 52

4.4.9. Le partitionnement ... 52

4.5. Conclusion ... 52

5. LA LOGIQUE DE REECRITURE & MAUDE ...53

5.1. Introduction... 54

5.2. Eléments de base... 54

5.3. Théorie de réécriture... 56

5.4. Applications de la logique de réécriture... 58

5.5. Maude : un Langage à base de Logique de Réécriture... 60

5.6. Le Système Maude... 60

5.6.1. Core Maude ... 62

5.6.2. Full MAUDE ... 62

5.7. Les modules Maude... 63

5.7.1. Modules Fonctionnels ... 63

5.7.2. Modules Systèmes ... 65

5.7.3. Les Modules Orientés-objets en Maude ... 66

5.7.4. Exemple récapitulatif ... 69

5.8. Conclusion ... 73

6. CONCEPTION D'UN SERVEUR DE POLITIQUES ...74

6.1. Introduction... 75

6.2. Le modèle d’information pour les politiques de QoS... 75

6.3. Le schéma fonctionnel du serveur de politiques de QoS... 78

6.4. Conclusion ... 81

7. CONCLUSION ET PERSPECTIVES ...82

CHAPITRE 1

1.1. Introduction

Pendant longtemps, les réseaux de communication étaient spécifiques à un seul type d’information et un seul type de service : les réseaux à commutation de circuit pour la téléphonie, les réseaux hertziens pour la télévision, les réseaux IP pour les données... Ces différents types de réseaux ont aujourd’hui tendance à converger, chaque opérateur voulant offrir de multiples services à ses clients : accès à Internet, téléphonie, télévision interactive, vidéo à la demande, visioconférence, télémédecine... Nous observons aussi l’émergence de nouvelles applications complètement distribuées permettant d’utiliser des ressources réparties sur un réseau ou sur internet : la téléphonie peer-to-peer (P2P) [Yu, 2003], le calcul distribué (grid computing, P2P computing), ou même la diffusion peer-to-peer de flux vidéo continus (voir par exemple [Cui et al., 2004]).

1.2. Contexte de travail

Les réseaux actuels sont désormais multiservices et hétérogènes. Outre cette multiplication des services dans les réseaux, ceux-ci sont de plus en plus exigeants quant à la qualité des transmissions. La notion de qualité de service permet de formaliser ces exigences en terme de critères de performance : bande passante, délai de transmission de bout en bout, taux de perte des paquets, gigue... et chaque service peut avoir des exigences différentes en terme de qualité de service. L’architecture best-effort établi par les réseaux IP dans les années 70 ne permet pas de garantir une quelconque qualité de service et il a été nécessaire de définir de nouvelles architectures de réseaux pour répondre à ces nouveaux besoins. De cette nécessité sont nées les architectures à intégration de service (réseaux ATM, modèle IntServ pour les réseaux IP) qui s’appuient sur une réservation préalable des ressources et un multiplexage statistique des trafics, et plus récemment les architectures à différentiation de services (modèle DiffServ, réseaux MPLS) qui effectuent un traitement différencié des trafics, regroupés en quelques classes de services, pour garantir la qualité de service. Toutefois ces architectures ne permettent pas de résoudre tous les problèmes et la maîtrise de la qualité de service reste aujourd’hui un défi majeur pour la recherche sur les réseaux multiservices.

L’introduction de mécanismes «intelligents» dans les réseaux multiservices permet de surmonter la difficulté de mettre en place des méthodes plus traditionnelles pour prendre en compte toute la complexité générée par la multiplication des services. Cela permet aussi de répondre à un autre besoin de plus en plus pressant : les réseaux doivent être de plus en plus autonomes et doivent s’adapter automatiquement aux conditions de trafic, à l’ajout de nouveaux services, aux congestions, aux pannes, etc. Ils doivent devenir «intelligents» (smart networks) ou «conscients d’eux-mêmes» « self-aware networks » . [Gelenbe et Núñez, 2003]). Les méthodes d’apprentissage

notamment permettent de répondre en partie à ces nouveaux besoins et la littérature scientifique en proposent de nombreuses applications.

C’est dans ce contexte général que se situent ces travaux de thèse. Nous nous intéressons au problème de l’évaluation de performance dans les réseaux, et plus spécifiquement l’évaluation des critères de qualité de service. Il s’agit d’un problème transversal aux différents mécanismes de gestion d’un réseau : pour être capable de garantir la qualité de service de chaque client, il faut en effet être capable d’en évaluer les différents critères. Traditionnellement, ce problème est résolu de deux manières : soit de façon analytique à l’aide de la théorie des files d’attente, soit de façon expérimentale par simulation (simulation par événements discrets ou simulation fluide). Ces deux approches sont complémentaires : la théorie des files d’attente permet d’obtenir des expressions analytiques (parfois exactes) de critères de performances sous des hypothèses relativement fortes et pour certains systèmes d’attente, tandis que la simulation a un pouvoir d’expression beaucoup plus important (a priori sans limite) mais se heurte à des temps de calcul prohibitifs.

Dans un travail antérieur [ZEMMOUCHI, 2003], nous avons abordé la QoS (qualité de service) par un chemin algorithmique pour établir de manière ad-hoc un lien entre les politiques de qualité de service et les annuaires LDAP comme structure de stockage des règles..

Nous proposons dans cette thèse un chemin formel qui conduit à préciser la nature contractuelle de la QoS dans les serveurs de politique.

1.3. Problématique et objectifs

La qualité de service au sein d’un réseau IP revient à regrouper les paquets d’un flux d’applications dans une certaine classe de trafic. Cette classification a pour objet d’accorder à ces paquets un traitement plus ou moins prioritaire par rapport à d’autres paquets. Ainsi, certains utilisateurs recevront un meilleur service que d’autres. Il est alors inévitable que des utilisateurs rechercheront à obtenir le meilleur service sans en payer le prix ou sans y être autorisé. On conçoit qu’il est nécessaire de disposer de certains mécanismes sur le réseau, afin de mettre en œuvre des règles de gestion de trafic, faisant appel à une architecture, à un certain nombre de protocoles et à des modèles de représentation des données sous forme d’objet. La complexité croissante d'un tel problème et le manque de la science proportionnée et technologie pour soutenir le développement robuste mène typiquement à des solutions qui sont fragiles, incertaines, et extrêmement difficiles d’évoluer. Tout ça impose la recherche des méthodes de spécification et vérification puissantes.

Dans ce contexte, l’introduction d’un cadre formel pour développer un serveur de politiques est d’un grand intérêt, il permet d’avoir une expression claire des propriétés du système à modéliser, ainsi qu’une vision cohérente et transparente de ce que le système fait et ne fait pas. Cette

formalisation est ensuite utilisée, pour donner une sémantique formelle à ce type de système en termes de logique de réécriture [Mes, 2002], un formalisme rigoureux de spécification, de prototypage et de vérification des systèmes.

L’objectif principal de ce travail est d’attribuer une sémantique formelle et opérationnelle, basée logique de réécriture, à un serveur de politiques gérant les qualités de service, permettant ainsi une compréhension approfondie du serveur par la mise en évidence des ambiguïtés laissées dans l'ombre par les spécifications informelles, ainsi que l'utilisation d'outils de preuve et d'évaluation symbolique existants autour de cette logique.

La logique en général est une méthode de raisonnement correct pour quelques classes de systèmes. Pour la logique équationnelle, les modèles des systèmes sont les ensembles, les fonctions entre ces ensembles et la relation d’identité entre les éléments. Pour la logique de réécriture, les entités sont les systèmes concurrents ayant des états, et qui évoluent à travers des transitions. Elle est considérée également comme une logique de changement concurrent qui traite l'état et les calculs concurrents.

Une politique de QoS est un ensemble de règles associées à certains services. Les règles définissent les critères à satisfaire pour obtenir ces services. Elles sont définies en fonction de conditions et d’actions, les actions découlant du respect des conditions. Dans la pratique, une règle pourra elle-même contenir d’autres règles. Ce principe de hiérarchie de règle permet de construire des politiques complexes à partir de règles simples. Le mode de définition de ces conditions et de ces actions doit être établi d’une façon globale, de sorte à maintenir une cohérence entre les différents domaines de gestion de politiques de QoS. En d’autres termes, un flux défini comme prioritaire dans un domaine de gestion (le réseau interne de l’entreprise) doit rester prioritaire s’il traverse un réseau d’opérateurs qui correspond à un autre domaine de gestion. Pour assurer cette portabilité des règles, il est nécessaire que la définition de celle-ci soit réalisée dans un langage de description de haut niveau, indépendant des équipements. Dans ce cas, nous exprimons alors ces règles (politiques) dans la logique de réécriture qui représente un cadre sémantique unificateur de plusieurs modèles de spécification.

Une politique peut se définir à différents niveaux. Le niveau le plus haut correspond à celui de l’utilisateur. La détermination d’une politique s’effectue par un dialogue entre l’utilisateur et l’opérateur. Ils utilisent pour cette négociation soit le langage naturel soit des règles déjà préparées par l’opérateur du réseau. Dans ce dernier cas, l’utilisateur ne peut sélectionner que des règles proposées par le réseau. Dans les deux cas, cette politique doit être traduite dans un langage de niveau réseau permettant de déterminer le protocole réseau de gestion de la qualité de service et son paramétrage. Ensuite, il faut traduire ce langage de niveau réseau en langage de bas niveau

correspondant à la programmation des nœuds du réseau, ce que l’on peut appeler la configuration du nœud.

Nous enrichissons, à travers l’approche proposée, le langage de niveau réseau par quelques structures basées logique de réécriture afin de décrire de façon non ambiguë les modèles de représentation des données considérés (sous forme d’objet) et les protocoles qui y sont autour.

1.4. Plan

Ce document est organisé en cinq chapitres. Le premier chapitre, porte sur les concepts clés de la qualité de service en général et celle qui se rapporte au réseau IP en particulier. Un intérêt particulier est donné à la présentation des modèles IntServ et DiffServ et leurs limites.

Dans le deuxième chapitre, des notions précises et claires concernant les politiques de services et les serveurs qui les gèrent sont données. On commence par donner la structure et l’architecture générique d’une politique de service, ensuite nous présentant un aperçu général sur les langages de spécification de politiques (ponder en particulier) et leurs intérêts en pratique. Enfin, on montre la solution souvent préconisée dans la spécification et la gestion des politiques de service et qui se base sur l’annuaire LDAP.

Le troisième chapitre détaille les concepts clés de LDAP : protocole, modèle de données, modèle fonctionnel et comment déployer un service d’annuaire LDAP, après avoir motivé convenablement cette approche dans la gestion des politiques de QoS.

Le quatrième chapitre est consacré à la présentation du formalisme logique de réécriture ainsi que la syntaxe du langage Maude basé sur cette logique. Un intérêt particulier est donné à la déclaration des modules orientés objets en Maude qui seront utilisés dans cette modélisation.

Dans le dernier chapitre, un nouveau support à base de logique de réécriture est proposé pour concevoir un serveur de politique QoS. L’approche de conception est inspirée de celle basé LDAP. Dans la première étape, un modèle d’information pour les politiques de QoS de type QPIM est défini en utilisant principalement les modèles orienté objet de Maude. Dans une deuxième étape, nous proposant un schéma fonctionnel formel d’un serveur de gestion de politiques de QoS en exploitant les caractéristiques syntaxiques et sémantique de Maude.

Une conséquence théorique importante se découle de cette étude concernant :

• Le prototypage et éventuellement la vérification de certaines propriétés dans Maude. • La formulation correcte des métas politiques.

• La structuration des politiques de QoS selon leur sémantique et régler ainsi le problème de conflit sémantique qui peut se poser dans certaine situations.

Le manuscrit se termine par une conclusion générale permettant de situer la présente contribution par rapport aux travaux réalisés dans le même contexte et d’évoquer les différentes continuations jugées possible pour ce travail.

CHAPITRE 2

2.1. Introduction

La "qualité de service" est une notion relativement controversée, même si les polémiques se sont calmées au cours de ces dernières années. Ce chapitre décrit les approches et les axes discutés pour introduire de nouveaux types de données comme les flux multimédia, la téléphonie, les simulations distribuées.

L'Internet a été conçu comme un réseau d'interconnexion entre des universités et des instituts de recherche aux Etats Unis. Le protocole IP "Internet Protocol" a permis un développement très rapide du réseau grâce à sa flexibilité et sa nature ouverte. IP s'est également imposé comme technologie réseau dans la plupart des réseaux privés. Pourtant, les paradigmes qui ont fait le succès de l'Internet imposent de fortes limitations aujourd'hui. Quand le protocole IP a été conçu, l'architecture réseau comptait peu de terminaux connectés, et les applications usuelles étaient telnet, l'email et le FTP. Avec la naissance du Web, l'âge de l'Internet commercial fut inauguré, donnant naissance à de nouveaux types d'utilisateurs, toujours plus avides de services et donc de bande passante. La consommation des utilisateurs a donc évolué aussi rapidement que l'Internet, l'augmentation des débits étant très vite rattrapée par une consommation accrue de nouvelles applications. L'apparition d'ordinateurs personnels plus puissants à des prix plus abordables a conduit à un formidable essor des développements d'applicatifs. Le paradigme "IP over everything" des premières années (focalisation sur le transport) a donc changé pour un paradigme de "everything

over IP" d'aujourd'hui (focalisation sur les services au dessus d'IP). L'Internet est présent presque

partout, générant des économies d'échelle et favorisant le développement d'un grand nombre d'applications, ainsi que l'adaptation des applications existantes sur IP. Toutes les applications imaginables, de la navigation sur le Web à la diffusion vidéo ou la téléphonie seront transportées par le même réseau.

L'apparition d'un tel réseau multiservice permettra de sur croie une utilisation optimale des ressources avec des coûts d'opération très réduits. Pour atteindre cet objectif, il s'avère néanmoins nécessaire de pouvoir différentier les applications entre elles de façon à leur offrir un traitement spécifique, conforme à leurs besoins et contraintes (de temps réel par exemple). Sous sa forme originelle, le protocole IP traite tous les éléments transportés de façon égale. La conséquence est qu'à certains moments, des applications n'auront pas les ressources minimales dont elles ont besoin, en revanche d'autres applications disposeront de ressources qu'elles n'utiliseront pas pleinement. Il est important de mentionner que les flux téléphonies requièrent de petites quantités de bande passante, mais nécessitent des délais de transport faibles et déterministes. De tels flux ne pourront donc pas être efficacement transportés dans un réseau IP sans mécanismes de QoS (Quality of

2.2. Gestion des flux

2.2.1. Intégration de service

Les travaux sur l'intégration de service dans l'Internet ont été pris en compte par trois groupes de travail :

• le groupe de travail RSVP "ReSerVation Protocol" [RFC 2205] porte mal son nom, car il a défini un protocole conçu pour transporter des messages de caractérisation (appelé aussi signalisation) de flux, il n'effectue aucune réservation ;

• le groupe IntServ "Integrated Services" définit les services qui peuvent être offerts. Cela passe par la description des caractéristiques des flux de données et les paramètres à indiquer lors d'une demande de réservation. Ces caractéristiques sont prévues pour être transportées dans les données des paquets RSVP ;

• le groupe de travail issll "Integrated Services over a Specific Link Layer" définit les méthodes pour traduire les caractéristiques de flux spécifiés par l'IntServ vers un niveau 2 particulier

Quand une source produit un flux de données, elle peut également émettre des messages de signalisation RSVP, décrivant les caractéristiques de celui-ci. Cette signalisation ayant la même destination que le flux (il peut aussi s'agir d'une adresse de multicast), traversera les mêmes routeurs intermédiaires qui y ajouteront leurs caractéristiques, principalement leur temps de traversée.

Les flux restent traités par les routeurs en"Best-Effort".Le destinataire recevant les messages de signalisation, en plus des données du flux, peut décider d'améliorer la qualité de celui-ci en envoyant un message de réservation vers la source pour demander aux routeurs d'améliorer le

traitement du flux. Mais le routage dans l'Internet n'est pas symétrique, il faut donc que les routeurs se souviennent pour chaque flux quel était le précédent routeur. Un contexte doit être établi dans chaque routeur pour chaque flux signalé par la source. A la réception d'un message de réservation, un contrôle d'admission est fait par le routeur pour déterminer si l'ajout d'un nouveau flux ne perturbera pas ceux pour qui une réservation a déjà été faite.

Le groupe de travail IntServ a actuellement défini deux types de services lors de la réservation : • Le service garanti [RFC 2212] est basé sur les résultats du "Network Calculus" [Le Boudec, 1997] qui permet de trouver une borne maximale pour le temps de transmission d'un paquet et la taille maximale des mémoires tampons nécessaires dans les équipements pour éviter les pertes de paquets. Le destinataire en fixant le débit minimal que doit offrir le réseau à ce flux influe sur le

temps maximal de transmission des paquets. Ainsi, pour réduire les temps de traversée, il est possible de réserver à un débit nettement supérieur à celui de la source.

• Le service contrôlé [RFC 2211] a une définition volontairement relativement vague : un service contrôlé offre un service proche de l'Internet peu chargé. Ce type de service a un intérêt si l'on considère que des outils de téléconférence comme "vat" pour la vidéo ou "vic" pour l'audio offrent une bonne qualité quand le réseau est peu utilisé, mais la qualité se dégrade très vite si le réseau est saturé.

Depuis que les travaux ont été finalisés, l'impact de ce protocole a surtout été politique. Il a conduit à prendre en compte le protocole IP dans ces travaux, en particulier ceux concernant la téléphonie sur l'Internet et à recommander son utilisation dans la norme H.323. Par contre aucune réalisation à grande échelle n'a été faite de ce protocole. Ceci pour plusieurs raisons :

• Le protocole ne résiste pas au facteur d'échelle, il faut mettre un état par flux signalé dans chaque routeur. Ceci n'est pas réalisable dans un réseau d'opérateur ou sur une liaison transatlantique.

Des propositions pour agréger les différentes réservations au sein d'un réseau d'opérateur ont été faites, mais elle implique qu'il faille aussi "désagréger" dans le réseau [Baker,Davie, 2000]. La vision qu'a un routeur est limitée au prochain saut, c'est-à-dire l'information contenue dans la table de routage. Ce n'est pas parce que plusieurs flux ont le même prochain routeur qu'il vont avoir le même routeur de sortie du réseau de l'opérateur. Par conséquent quelque part dans le réseau, ces flux seront séparés, mais l'agrégation de la signalisation aura fait perdre leurs caractéristiques individuelles.

• Les bornes offertes par la classe de service garanti sont trop pessimistes, ce qui limite le nombre de flux pouvant obtenir une réservation.

• Il n'existe pas de modèle économique et technique pour facturer les ressources réservées dans le réseau et les utilisateurs doivent être capable de comprendre la relation entre le coût et la qualité des réservations.

Il s'en suit que si la réservation de ressource est utilisée dans l'Internet, elle le sera uniquement au niveau d'un système autonome et pas de bout-en-bout. Les problèmes de facturation sont grandement simplifiés. Puisqu'il sera possible d'agréger des flux ayant un même routeur de sortie chez un opérateur, de limiter le nombre de flux à signaler (donc de réduire le nombre de contextes dans les routeurs) et d'offrir une plus grande pérennité au flux. Dans les sites terminaux, l'usage de la réservation est plus contestable car il est beaucoup plus facile d'augmenter la capacité du réseau pour se trouver dans une situation de "gaspillage" de bande passante ou d'introduire des priorités sur les flux que d'administrer un réseau mettant en œuvre de la réservation de ressources. Les seuls cas

où cette augmentation de capacité est difficilement réalisable sont les réseaux sans fils et les réseaux Intranet utilisant des liens longues distances.

2.2.2. Différenciation de services

La différenciation de services [RFC 2475] consiste dans une situation de congestion à reporter les pertes de paquets sur certaines classes de trafic, pour en protéger d'autres. Elle n'offre donc aucune garantie sur les flux, car il n'existe à aucun moment un contrôle d'admission dynamique permettant d'éviter une congestion. Le contrôle d'admission est fait a priori par la définition d'un contrat pour chaque classe de trafic et par le dimensionnement des ressources pour pouvoir garantir ce contrat. La différenciation de service présente les avantages suivants :

• La signalisation est faite dans chaque paquet (IPv4 ou IPv6) en attribuant une signification différente aux bits du champ type de service [RFC 2474]. Il n'est plus besoin de garder dans le routeur un contexte liant le flux de signalisation au flux de données. Cela permet aussi une agrégation naturelle des flux, ainsi pour un opérateur, les paquets qu'il reçoit marqués pour une certaine classe peuvent appartenir à plusieurs sources.

• La complexité du traitement est concentrée dans les routeurs aux frontières du réseau. Ils effectuent les opérations " complexes " de contrôle de la validité du contrat pour les différentes classes de trafic. Dans le cœur du réseau, le traitement est plus simple, ce qui autorise un relayage rapide des paquets.

• La tarification du service est plus simple, il suffit, comme avec "Frame Relay", de définir les ¨Paramètres de contrôle de classes de services. Les travaux sur l'architecture à différenciation de services ont surtout porté sur la définition d'une architecture la plus générale possible, permettant aux opérateurs de développer facilement des classes de services adaptées aux besoins de leurs clients. Néanmoins, deux classes de services sont en cours de définition :

• La classe "Expedited Forwarding" [RFC 2598] offre un service de liaison virtuelle à travers le réseau d'un opérateur. Le contrat porte sur un débit constant. Les paquets excédentaires sont lissés ou rejeté à l’entrée pour toujours rester conforme au contrat. L'opérateur s'engage à traiter ce trafic prioritairement. Van Jacobson propose d'utiliser une priorité stricte pour traiter ces flux. Pour qu'un tel service soit performant, il faut qu'il ne représente qu'une faible partie du trafic total pour qu'aucun paquet marqué EF ne soit rejeté dans le cœur du réseau. Le service pouvant être l'interconnexion de sites via un service de réseaux privés virtuels mis en place par un opérateur. • Les classes "Assured Fowarding" [RFC 2597] définissent 3 priorités (notées par une couleur vert, orange, rouge) définissant l’ordre de rejet dans un routeur en cas de congestions. Les paquets rouges ont une probabilité de rejet plus important que les paquets oranges. La couleur dépend de la

conformité de la source avec son contrat. Le marqueur actuellement préconisé pour déterminer la couleur du paquet est basé sur "tokens buckets" [RFC 2698]: si le trafic est conforme aux deux, les paquets sont marqué en vert, s'il n'est conforme qu'à un des "tokens buckets", les paquets seront marqués en orange et s'il n'est conforme à aucun des "tokens buckets" il est marqué en rouge. Dans le cœur du réseau, les mécanismes de rejet sont basés sur RIO [Clark, Fang, 1998], une extension à plusieurs priorités de RED. Chaque couleur dispose d'un seuil et d'une probabilité de rejet différente. Quatre classes AF (notées AF1, AF2, AF3 et AF4) sont disponibles. Toujours pour être le plus général possible, l'IETF ne définit pas de priorité parmi ces classes. On peut donc imaginer attribuer les classes en fonction par exemple d'un ratio temps de traversée des paquets taux de perte qui pourrait être utilisé pour différencier, par exemple, les services multimédias interactifs, de streaming ainsi que les données. Une autre solution pourrait être d'affecter une classe pour le trafic UDP et une autre pour le trafic TCP ce qui permet de ne pas détruire l'équité entre les flux TCP. Contrairement aux travaux du groupe IntServ qui partaient de la base théorique du "Network Calculus", ceux du groupe DiffServ, sont surtout basés sur une approche d'ingénierie portant sur la définition de l'architecture et sur la gestion de l'octet DS, mais les travaux effectués sur les classes de service d'ATM devraient pouvoir être repris et facilement applicables dans le contexte Internet. Il faut pouvoir arriver à déterminer les paramètres de configuration des équipements.

Les classes de service DiffServ ont été présentées dans l'optique d'un opérateur unique. Or le trafic peut traverser plusieurs systèmes autonomes. Il faut donc un critère de comparaison entre les classes de services. L'exemple le plus marquant est le concept de "Bandwidth Broker", vaguement introduit par Van Jacobson pour la classe de service EF. Le "Bandwidth Broker" a pour fonction de négocier les paramètres de la classe EF avec les autres systèmes autonomes. La difficulté réside, comme pour l'agrégation des flux de réservation dans IntServ, en la prise en compte des routes prises par ceux-ci lors des négociations. Or l'exemple pris par Van Jacobson ne prend en compte qu'une succession linéaire de domaine. Une des possibilités pour intégrer la route prise par les paquets serait de travailler dans les bases de données d'état des liens du protocole de routage interne (OSPF, IS-IS) qui contiennent une vision beaucoup plus précise (quoique toujours incomplète) de l'état du réseau. Enfin, une méthode importante aussi bien dans la phase de validation des services que dans celle d'exploitation, sera l'utilisation de critères objectifs pour caractériser les performances des classes de services. Le groupe de travail IPPM"IP Performance Measurement" [RFC 2330] de l'IETF a défini un certain nombre de critères pour mesurer en particulier le temps d'aller simple d'un paquet dans le réseau. Pour augmenter la précision des mesures, des horloges synchronisées avec les systèmes GPS permettent une synchronisation précise de tous les sites. Quand le service de différenciation sera mis en place les clients pourront aussi se servir de ces mécanismes pour valider le réseau de leur

2.2.3. Intégration IntServ / DiffServ

L'intégration de ces deux mécanismes est à l'étude. Plusieurs propositions ont été soumises. La première solution consiste à ne mettre l'intégration de service que dans les sites terminaux. Le cœur du réseau ne traite pas les messages de signalisation, mais les transmet comme des paquets normaux qui sont à nouveau interprétés dans le site destinataire. Un contrôle d'admission en bordure du réseau DiffServ permet de déterminer si le flux peut entrer dans la classe de service.

L'autre possibilité consiste à considérer le réseau DiffServ avec la classe EF comme un élément de réseau [Zhang, Yavatkar, 2000] et le caractériser pour permettre de construire un service garanti.

2.2.4. Ingénierie de trafic

L'ingénierie de trafic peut être un autre moyen d'augmenter la qualité du service, en dimensionnant plus finement les ressources dans le réseau de l'opérateur. Elle peut être liée au routage par qualité de service ou à l'utilisation de la différenciation de services, par exemple pour protéger certains flux d'un trop grand nombre de pertes. Il s’agit alors d’adapter le comportement du réseau à chaque classe de service en modifiant le routage et/ou le traitement dans les équipements intermédiaires. L’adaptation du routage à chaque qualité de service peut se faire de différentes manières, la plus évidente étant sans doute d’établir dans tous les routeurs du réseau une table de routage différente pour chaque qualité de service. Bien qu’OSPF en prévoyait la possibilité, cette solution n’a pas été employée parce qu’elle est coûteuse en mémoire et ne permet pas aux opérateurs de maîtriser les routes prises par les paquets. En effet, celles-ci sont construites automatiquement par le protocole de routage qui se base sur une métrique associée à chaque lien. Si la manipulation des métriques permet de favoriser ou de défavoriser tel lien et donc d’influencer le chemin parcouru par les paquets, elle reste d’une utilisation complexe. Les opérateurs préfèrent la possibilité d’établir des chemins protégés (fixés à l’avance) dans le réseau et d’utiliser un chemin donné pour un trafic donné. Ce trafic peut correspondre au trafic d’un client ou d’un réseau privé virtuel (VPN : Virtual Private Network) particulier, ou appartenir à une classe de service donnée.

Il est possible d’utiliser de tels tunnels avec des technologies orientées circuits comme ATM ou Frame Relay, celles-ci permettant aussi d’attribuer des ressources réservées aux chemins (circuits). Malheureusement, non seulement l’administration de ces réseaux est complexe et peu automatisée,

mais l’utilisation d’un cœur de réseau ATM ou "Frame Relay"directement au-dessous d’IP suppose un maillage logique (à base de circuits) complet des routeurs de bordure pour chaque qualité de service. Chaque routeur d’entrée choisit en fonction du paquet et de la qualité de service qui lui est associée le circuit conduisant au routeur de sortie avec la qualité de traitement correspondante. Aujourd’hui MPLS "Multi Protocol Label Switching" [Callon, Swallow, 1999] permet de simplifier l’administration d’un tel coeur de réseau en ajoutant de nouvelles fonctionnalités particulièrement intéressantes pour la gestion de la qualité de service. Dans le même esprit que l’architecture DiffServ, MPLS permet de réduire le coût des traitements associés au relayage des paquets en les reportant à la périphérie du réseau et en en réduisant la fréquence. Il apporte aussi un mécanisme de routage hiérarchique efficace, c’est-à-dire des tunnels permettant de gérer les réseaux privés virtuels (VPN).

Le principe de MPLS est d’attribuer un label (une étiquette) à chaque paquet lorsqu’il entre dans le réseau. Ce label est attribué en fonction de la classe de relayage (FEC : Forwarding Equivalent Classe) à laquelle appartient le paquet. La définition de ces classes dépend de l’opérateur du réseau, généralement une classe correspond à une entrée de la table de routage ou à un routeur de sortie du réseau, mais elle peut aussi prendre en compte la classe de service DiffServ. Le routeur décide de la FEC à laquelle appartient un paquet en fonction des informations contenues dans son en-tête (adresse destination, classe de service DiffServ, appartenance à un VPN, ...) et éventuellement de la connaissance qu’il a de la topologie du réseau. Une fois à l’intérieur du réseau les paquets ne sont plus traités qu’en fonction du label qui leur a été associé et l’en-tête IP n’est plus consulté. Ce label décide donc dans chaque routeur : du prochain routeur, du comportement DiffServ et de l’utilisation éventuelle des ressources réservées.

2.3. Conclusion

On peut dire que ni IntServ ni DiffServ ne sont des modèles parfaits répondant à toutes les exigences d'une bonne qualité de service. En effet, IntServ est très performant et bien adapté aux réseaux de petite envergure, alors que DiffServ s'adapte mieux à des réseaux de grande échelle. Cependant, la mise en œuvre de l’ensemble des mécanismes décris est une tache très lourde, il est difficile de configurer manuellement l’ensemble des équipements réseau pour deux raisons essentielles :

• l’abondance des informations de QoS,

• la nature dynamique des configurations de QoS.

L'IETF a ouvert plusieurs directions pour l'amélioration de la qualité de service. Aucune de ces techniques n'est universelle, mais on assiste en ce moment à une convergence et une interaction entre ces différentes technologies. Elles donnent aux opérateurs des outils permettant une meilleure gestion des flux. Les techniques de réservation de ressources impliquent une certaine stabilité et une pérennité. Elles ne peuvent être déployées que dans le cœur du réseau.

Nous aborderons dans le chapitre suivant une approche de gestion du réseau pour l’amélioration de la qualité de service en utilisent la notion de politique. Cette approche devient une solution idéal pour les réseaux de grandes dimensions.

CHAPITRE 3

3.1. Introduction

La qualité de service au sein d’un réseau IP revient à regrouper les paquets d’un flux d’applications dans une certaine classe de trafic. Cette classification a pour objet d’accorder à ces paquets un traitement plus ou moins prioritaire par rapport à d’autres paquets. Ainsi, certains utilisateurs recevront un meilleur service que d’autres. Il est alors inévitable que des utilisateurs rechercheront à obtenir le meilleur service sans en payer le prix ou sans y être autorisé. On conçoit qu’il est nécessaire de disposer de certains mécanismes sur le réseau, afin de mettre en œuvre des règles de gestion de trafic, faisant appel à une architecture, à un certain nombre de protocoles et à des modèles de représentation des données sous forme d’objet. Pour cela l’architecture de serveur de politique et la notion de politique deviens une approche innovatrice.

3.2. Définition d’une politique de QoS

Une politique de QoS est un ensemble de règles associées à certains services. Les règles définissent les critères à satisfaire pour obtenir ces services. Elles sont définies en fonction de conditions et d’actions, les actions découlant du respect des conditions. Dans la pratique, une règle pourra elle-même contenir d’autres règles. Ce principe de hiérarchie de règle permet de construire des politiques complexes à partir de règles simples. Le mode de définition de ces conditions et de ces actions doit être établi d’une façon globale, de sorte à maintenir une cohérence entre les différents domaines de gestion de politiques de QoS. En d’autres termes, un flux défini comme prioritaire dans un domaine de gestion (le réseau interne de l’entreprise) doit rester prioritaire s’il traverse un réseau d’opérateurs qui correspond à un autre domaine de gestion. Pour assurer cette portabilité des règles, il est nécessaire que la définition de celle-ci soit réalisée dans un langage de description de haut niveau, indépendant des équipements [Mélin 2001].

Une politique peut se définir à différents niveaux. Le niveau le plus haut correspond à celui de l’utilisateur. La détermination d’une politique s’effectue par un dialogue entre l’utilisateur et l’opérateur. Ils utilisent pour cette négociation soit le langage naturel soit des règles déjà préparées par l’opérateur du réseau. Dans ce dernier cas, l’utilisateur ne peut sélectionner que des règles proposées par le réseau. Dans les deux cas, cette politique doit être traduite dans un langage de niveau réseau permettant de déterminer le protocole réseau de gestion de la qualité de service et son paramétrage. Ensuite, il faut traduire ce langage de niveau réseau en langage de bas niveau correspondant à la programmation des nœuds du réseau, ce que l’on peut appeler la configuration du nœud [RFC 2753].

3.3. Structure et architecture d’une politique de QoS

Une architecture générique a été définie par l'IETF qui permet la mise en œuvre d’un contrôle d’admission des requêtes d’allocation de ressources fondé sur la mise en œuvre de politique

(policy-based admission control). Le contrôle ou la gestion par politique implique plusieurs composants :

les nœuds du réseau prennent le nom de PEP (Policy Enforcement Point). Les politiques y sont appliquées pour gérer le flux des utilisateurs. Le PDP (Policy Decision Point) est l’élément qui prend les décisions et choisit les politiques à appliquer aux PEP. Le système comporte également une console utilisateur qui regroupe des outils de gestion des politiques. Elle permet notamment de stocker, de mémoriser les politiques dans une base de données nommée Policy Repository, qui entrepose les règles de politique que le PDP pourra rechercher pour les appliquer aux nœuds du réseau [RFC 2753]. La figure 1 présente l'architecture proposée par l'IETF pour la prise en charge des politiques de QoS.

Figure 1 : Architecture générique PDP

PEP PEP PEP

Policy Repository

LDAP

Policy management

3.3.1. Le PDP (policy décision point)

Le PDP est défini comme une entité logique prenant des décisions politiques pour lui-même ou pour d’autres éléments du réseau qui demandent ses décisions. Le PDP ou serveur de politique, est donc le point central qui doit décider des politiques à appliquer dans le réseau. Le PDP 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 être distants.

Le principal serveur est le policy repository dans lequel le PDP vient rechercher les règles de politique, cette mémoire communique avec le PDP par le protocole LDAP (Lightweight Directory

Access Protocol) ce qui explique son nom de serveur LDAP.

Il peut exister des serveurs complémentaire comme la PIB (Policy Information Base) qui garde en mémoire les modèles informationnelles qui peuvent être utilisés pour représenter une politique sous une syntaxe particulière. Le rôle du PDP consiste à identifier les règles de politiques qui sont applicable aux différents PEP et à déterminer les règles à appliquer stratégiquement à ces PEP. Le PDP doit également se préoccuper de la traduction des règles de politique dans des formats compréhensibles des nœuds comme le format PIB. De plus il doit pouvoir communiquer avec d’autres serveurs internes pour ses décisions. Enfin, le PDP assure la distribution des configurations. En résumé, le PDP décide des règles à appliquer et envoie les ordres de configuration aux nœuds du réseau [RFC 2753].

3.3.2. Les PEP (Policy Enforcement Point)

Les PEP sont des entités logiques qui appliquent les décisions en terme de politique prises par le PDP dont elles dépendent. Les PEP sont généralement les nœuds du réseau, qui peuvent être de différents types (routeurs, commutateurs, etc.). Un PEP peut également être un firewall ou un équipement intermédiaire entre le client et le réseau. Un PEP doit être facilement accessible par PDP de sorte qu’il soit possible de le configurer sans problème [RFC 2753].

Il faut noter que la séparation du PEP, du PDP et de l’annuaire (policy repository) est logique et ne correspond pas forcément à une mise en œuvre physique. Ainsi, il est parfois possible que l’ensemble des composants soient situés sur un seul nœud du réseau. Dans d’autre cas, les nœuds du réseau peuvent comprendre un PEP et un PDP local, devant être complété par un PDP global. Dans ce cas, le PDP associé au PEP sera appelé LPDP (local policy décision point) et permettra d’appliquer une politique locale à l’équipement. Cependant, l’architecture prévoit, pour éviter des trous de sécurité, que LPDP se réfère à un PDP pour la décision finale quant à la politique à appliquer. L’architecture précise également qu’il est possible d’en avoir plusieurs (PDP/base de

données des politiques associées) pour fiabiliser la gestion du réseau et introduire un niveau de redondance. Ce nombre doit être limité afin de simplifier l’administration [Mélin 2001].

On considère que les trois fonctions suivantes doivent être associées à une politique :

• La fonction de décision : cette fonction réalisée par le PDP suppose la recherche d’une politique, son interprétation, la détection de conflits entre politiques, la réception de la description des interfaces des équipements, la réception des requêtes de PEP, la détermination de la politique à appliquer.

• La fonction d’application (enforcement) : cette fonction implique un PEP agissant selon les décisions du PDP, en fonction des politiques à appliquer et des conditions du réseau.

• La fonction de mesure (metering) : cette fonction permet de vérifier la mise en place de la politique et son respect.

Outre les composants décrits ci-dessus, cette architecture recourt à deux protocoles majeurs :

• COPS (Common Open Policy Service) : c’est le protocole sécurisé permettant les échanges entre les PEP et les PDP [RFC 2748].

• LDAP (Lightweight Directory Access Protocol) : c’est le protocole utilisé pour accéder à la base de données des règles [RFC 2251].

3.4. Les langages de politique (Policy Language)

La politique est quelque chose qui contrôle l'information, c'est-à-dire le trafic des utilisateurs. Mais pourquoi faut-il le contrôler ? Parce qu'il existe de contraintes à imposer dans le réseau, telles que :

• l'intégration des différents médias

• les ressources qui ne sont pas infinies

• les applications ont des besoins divers (délai, bande passante, sécurité, etc.)

Les politiques réseau ont pour but de gérer les éléments du réseau pour satisfaire les différentes contraintes de l'utilisateur. Différentes vues abstraites de la politique réseau ont été définis. Au niveau le plus haut (niveau réseau), se trouvent les SLA (Service Level Agreement) qui correspond à un contrat entre l'utilisateur et le fournisseur réseau. Un SLA contient une partie technique liée aux paramètres réseau appelée SLS (Service Level Specification) et SLO (Service Level Objectives) qui présente les objectifs qui se fixe l'opérateur. [RFC 3198].

Dans le niveau suivant (niveau routeur), se trouvent les règles de politiques. La gestion par politiques va automatiser la configuration du réseau. Différents types de politiques existent :

• de configuration,

• d'installation,

• de contrôle d'erreurs et événements, de sécurité.

Dans l’approche de gestion de la QoS à base de politique, la qualité de service est négociée sous forme de SLA. La gestion des ces SLA et de la QoS représente une nouvelle question qui doit être abordée. Il faut regarder la façon dont les SLA sont décrits ainsi que la gestion et la présentation des paramètres de QoS. Plus spécifiquement, des langages de politique de gestion de service ont été définis dans lesquels un administrateur peut publier et commander les ressources fondamentales du réseau. L'architecture proposée soutient également la conception d’applications de gestion à base de politique à l'aide d’un langage d'interprétation de politique, d'une interface graphique, et d'un dépôt de politique.

La vérification et la validation des politiques ont suscité beaucoup d’intérêt dans la communauté de l’informatique. Cette problématique à motivé le développement d’une panoplie de langages, nous passeront en revue les langage de politique qui existe et nous mettront l’accent sur un en particulier qui et le langage de spécification de politique Ponder.

.

3.4.1. Langage PFDL (Policy Framework Definition Language)

Le PFDL est un langage de l'outil de l'administrateur de réseau pour exprimer divers genres de politiques de réseau. Ceci peut inclure des politiques de sécurité, politiques de qualité de service, ce langage est issu du modèle PCIM. PFDL voit une politique comme ensemble de règles pour un domaine donné. Alternativement, une règle définit un ordre des actions qui peuvent être déclenchées en raison de quelques conditions. Des conditions sont faites d'un type et d'une valeur. Leur exécution peut être séquentielle, conditionnelle, aléatoire (mode de défaut) ou basée sur des résultats des règles semblables [Strassner 1998].

3.4.2. Langage ProNet

C’est un langage qui à une syntaxe simple et qui a été adopté afin de représenter des politiques et des règles. Il est basé sur deux concepts principaux, à savoir, les politiques et les événements. Un programme écrit dans ProNet se compose d'un ensemble constructions d'où chacune de ces derniers représente une définition, un instanciation, une liste et/ou un déplacement d'une politique ou d'un événement, ou une invocation de service [Fidalgo 2002].

3.4.3. Langage Ponder

Ponder [Damianou, Dulay, 2000] [Damianou, 2002] est un langage de spécification de politiques de contrôle d'accès pour les systèmes distribués. Ce langage se base sur les notions suivantes

- Le Sujet (Subject) fait référence aux utilisateurs, programmes ou toute autre entité qui peut accéder à une ressource ou un service.

- La Cible (Target) fait référence aux ressources et aux services partagés dans un réseaux de communication ou dans un système. Les cibles sont accessibles par les sujets selon les politiques de Ponder.

- Les sujets et les cibles sont regroupés en Domaines (Domains).

Le langage Ponder considère plusieurs types de politiques de contrôle d'accès. Nous allons introduire ces types dans les paragraphes qui suivent.

Politiques d'autorisation

Les politiques d'autorisation définissent l'ensemble des actions permises et défendues pour un ensemble de sujets et sur un ensemble de cibles. Elles peuvent également être validées par un ensemble de contraintes. Ces contraintes vont être présentées dans la sous-section suivante.

Politiques de filtrage de l'information

Les politiques de filtrage servent à sélectionner l'information accessible aux sujets.

Ces politiques sont associées aux actions dans les politiques d'autorisations. Comme exemple, nous pouvons considérer la politique d'autorisation suivante :

Une politique de filtrage de l'information est associée à la politique d'autorisation nommée

VideoConference. Cette politique autorise aux membres des groupes /Agroup et /Bgroup d'initialiser

une vidéoconférence avec les membres du groupe USAgroup excepté ceux de NYgroup. L'initialisation d'une vidéoconférence prend comme paramètres la bande passante (BW) et la priorité (Priority). Une politique de filtrage est associée à cette action, elle limite la bande passante à 2MB/s et établit sa priorité à 3.

Politiques de délégation

Les politiques de délégation autorisent un ensemble d'utilisateurs à transférer les autorisations d'accès, en entier ou en partie, qu'ils possèdent à un autre ensemble d'utilisateurs. Un sujet peut donc déléguer à un autre utilisateur les droits qu'il possède.

Dans cet exemple le groupe Agroup délègue à Cgroup la politique d'autorisation VideoConference. La politique de délégation est appelée DelegVC.

Politique de retenue

Les politiques de retenue (Restrain Policies) sont des politiques qui empêchent un groupe de sujets d'exécuter un ensemble d'actions sur un ensemble de cibles. Les politiques de retenue sont similaires aux politiques d'autorisation négatives, mais ces dernières sont gérées par les cibles alors que les politiques de retenues sont gérées par les sujets.

Politiques d'obligation

Les politiques d'obligation spécifient les actions à entreprendre à la suite d'un événement.

La politique de l'exemple ci dessus est déclenchée à la suite de trois échecs d'authentification successifs par les sujets du domaine /NRegion /SecAdmin accédant au domaine /NRegion/users. La politique désactive le sujet et écrit son identificateur dans le journal.

a) Composition des politiques

Le langage Ponder offre la possibilité de structurer les politiques de contrôle d'accès en des groupes de politiques. Un groupe peut contenir des politiques ou des sous-groupes. Le regroupement des politiques peut avoir deux objectifs :

- structurer et organiser les politiques pour faciliter l'accès et la réutilisation et là on parle de groupe (group)

- structurer les politiques selon leur sémantique et les associer à un domaine de sujets et là on parle de rôle

b) Contraintes dans Ponder

Les contraintes des politiques de contrôle d'accès servent à spécifier les conditions de validité et d'applicabilité des politiques. Dans Ponder, il y a deux types de contraintes les contraintes relatives à une seule politique et les contraintes relatives à un groupe de politiques : métapolitiques.

Contraintes relatives à une seule politique

Les contraintes relatives à une seule politique sont spécifiées au niveau des politiques d'autorisation avec des prédicats. Ces contraintes peuvent être basées sur :

- les sujets et les cibles

- les paramètres des actions et des événements - le temps (date et heure)

L'exemple ci-dessus montre la même politique d'autorisation de la sous-section précédente mais qui possède une contrainte sur le temps. Ainsi, cette politique n'est appliquée qu'entre 16h00 et 18h00.

Métapolitiques

Les métapolitiques ont pour objectif de définir des contraintes sur un ensemble de politiques. Une méta-politique utilise un sous-ensemble de OCL (Object Constraint Language [Group, O.M, 2003]). Une contrainte est exprimée avec des d'expressions OCL qui peuvent déclencher l'exécution d'actions.

c) Conflits dans Ponder

Dans la mesure ou plusieurs politiques peuvent s'appliquer à un contexte particulier, des conflits peuvent exister entre elles. Dans Ponder deux types de conflits peuvent être détectés et analysés [Lupu et Sloman, 1997] [Lupu et Sloman, 1999] : les conflits de modalité et les conflits sémantiques.

Conflits de modalité.

Si des politiques positives et négatives s'appliquent pour les mêmes sujets, cibles et actions, alors il y aura un conflit de modalité. Ce type de conflits survient lorsque les domaines des politiques chevauchent (domaines des sujets, cibles et actions).

Pour résoudre ce genre de conflits, des règles de priorité et de préséance peuvent être établies afin d'aboutir à une seule décision. Comme relations de préséance nous pouvons citer :

Les politiques négatives ont toujours la priorité Des priorités explicites sont assignées aux politiques Considérer les politiques les plus spécifiques

Ce genre de conflits est détecté par l'outil Ponder Toolkit .

Conflits sémantiques

Les conflits sémantiques sont des situations non conformes aux spécifications d'un système. Ces conflits sont spécifiques aux applications et aux contextes associés. Ces conflits dépendent des facteurs externes tels que la disponibilité des ressources ou bien des politiques externes telles que les politiques globales dans une entreprise. Nous pouvons citer les exemples suivants :

- Séparation des taches : une même personne ne peut pas autoriser et initier le même paiement.

- Conflits des ressources : une ressource n'est disponible qu'en quantité limitée. - Un administrateur a toujours la priorité d'accès.

Ces situations peuvent générer des conflits sémantiques. En effet, les conflits sémantiques sont le résultat de la contradiction entre les politiques et les propriétés du système. Pour traiter ce genre de conflits les métapolitiques sont utilisées pour caractériser ce genre de situation (OCL) et effectuer les actions nécessaires.

d) Outils pour la détection de conflits

Ponder Toolkit est une suite d'outils [Damianou, 2002] permettant de gérer et d'analyser les politiques de contrôle d'accès dans un environnement distribué. Cette suite intègre un outil d'analyse des conflits de modalité (Conflict Analyzer ). Cet outil est implémenté en Java et détecte le chevauchement des domaines et les présente sous un format graphique.

La figure ci-dessous montre le résultat obtenu pour la détection de conflits de modalité pour six politiques d'autorisations, trois politiques positives (les clés) et trois politiques négatives (les clés barrées). La relation de chevauchement est représentée par un arc orienté de la politique la plus spécifique vers la politique la plus générale. Nous pouvons bien remarquer que les politiques positives chevauchent avec les politiques négatives, ce qui peut etre une source de conflit. Par exemple la politique positive Org1_authorisation1 annule la politique négative

Org3_authorisation2 car leurs domaines chevauchent.

La figure ci-dessus montre un exemple de conflit. Les sujets des domaines O2_m1 et O2_m2 peuvent effectuer les opérations retract(), delete() et disable() sur les cibles du domaine

SharedPolicies puisque la politiques Org2_authorisation1 l'autorise. Mais, les politiques Org1_authorisation2 et Org3_authorisation2 ne l'autorisent pas. L'outil permet également de

transformer les politiques et les métapolitiques en des prédicats en Prolog afin de détecter les conflits sémantiques.

Les travaux réalisés sur Ponder restent spécifiques à ce langage. La vérification et l'analyse se font avec deux techniques différentes pour les conflits de modalité et les conflits sémantiques. Ces deux types de conflits sont étroitement liés mais il n'y a pas un seul outil qui les traite. De plus, malgré que les métapolitiques représentent une technique efficace pour traiter les conflits, il existe encore un risque que les métapolitiques soient elles mêmes incohérentes

3.5. Conclusion

.

Dans ce chapitre, nous avons proposé une approche de gestion autonome, basée sur des politiques , adaptée aux réseaux IP multimédia pour le support de la QoS de bout en bout. Cette approche permet d'automatiser la gestion des ressources à l'intérieur de chaque équipement afin de satisfaire les objectifs de l'administrateur.

Afin de réaliser cette proposition, nous allons étudier la manière dans le politiques sont stoker, pour cela l’annuaire LDAP reste la solution préconisée, le chapitre suivant présente en détail les principaux concepts des annuaire LDAP

CHAPITRE 4

4.1. Introduction

Un annuaire est un recueil de données dont le but est de pouvoir retrouver facilement des ressources (généralement des personnes, des ressources informatiques ou des organisations) à l'aide d'un nombre limité de critères. Les annuaires électroniques sont un type de base de données spécialisée permettant de stocker des informations de manière hiérarchique et offrant des mécanismes simples pour rechercher l'information, la trier, l'organiser selon un ou plusieurs critères. L'utilisation d'annuaire ne se limite pas à la recherche de personnes ou de ressources. En effet, un annuaire peut servir à :

• constituer un carnet d'adresse,

• authentifier des utilisateurs grâce à des mots de passe, • définir les droits sur des utilisateurs de l’annuaire,

• recenser des informations sur un parc matériel (ordinateurs, serveurs, leurs adresses IP, etc.),

• décrire les applications disponibles et gérer leurs droits.

Etant donné le grand nombre d'enregistrements que peut comporter un annuaire, plusieurs milliers voire un million pour les mises en œuvre les plus importantes, il n'est parfois pas concevable de créer un annuaire centralisé contenant les informations de toutes ces entrées. C'est la raison pour laquelle les serveurs d'annuaires doivent être capables de communiquer entres eux afin de partager l'information. C’est la grande force et l’avantage du protocole LDAP. Pour des grandes entreprises, un annuaire doit pouvoir être interrogé sur les adresses de personnes de différentes filiales localisées dans des régions géographiquement éloignées. Les serveurs d'annuaires possèdent la faculté de se répliquer, c'est-à-dire d'offrir des fonctions permettant d'importer et d'exporter des enregistrements (on dit généralement synchroniser) avec d'autres annuaires. On parle ainsi de réplication ou bien de synchronisation. La synchronisation est peut être assurée de deux manières différentes :

• Grâce à des mécanismes de synchronisation intégrés par les produits du marché dans le système d’administration de l’annuaire

• Grâce à des outils appelés méta-annuaire (on parle aussi parfois de proxy LDAP). On distingue habituellement deux types de méta-annuaire. Les méta-annuaires avec réplication créant une base de donnée issue de l'agrégation des données provenant des différents annuaires et les méta-annuaires virtuels créant des références centrales vers les données contenues dans les différents annuaires, mais ne dupliquant pas l'information.

4.2. Les concepts de LDAP

Dans le cadre de l'utilisation en mode client-serveur de la couche applications du modèle OSI, la fonctionnalité des annuaires (administration, authentification et contrôle de d'accès) a été élaborée à l'origine pour traiter la gestion des adresses électroniques. A partir de ces concepts, il a été reconnu qu'il y avait une utilisation possible avec plusieurs autres applications. Par conséquent, elle a été définie comme une norme ou un module distinct dans la recommandation X.500 de l'UIT-T [X.500]. Bien que la couverture ait été complète, les personnes chargées de la mise en œuvre à cette période, l'ont critiquée comme étant trop complexe et, par conséquent, trop difficile à mettre en œuvre.

Pour aborder ce problème du service annuaire DAP qui était trop complexe à mettre en œuvre, l'université du Michigan a élaboré une version plus simple du DAP basée sur TCP/IP en vue d'une utilisation sur Internet. Le LDAP offre de nombreuses fonctionnalités du DAP d'origine et on peut l'utiliser pour interroger des données d'annuaires exclusifs aussi bien que d'un service ouvert X.500. Au fur et à mesure des années, la plupart des fournisseurs importants de logiciels de courrier électronique et de services d'annuaires se sont montrés intéressés par le LDAP, celui-ci est maintenant le véritable protocole d'annuaire utilisé pour Internet.

4.2.1. Le protocole LDAP

Bien que le LDAP ait commencé comme un simple composant de l'annuaire X.500, il évolue en un service d'annuaire complet. En se servant des services de noms d'Internet, les réalisateurs construisent des couches de sécurité et ajoutent des capacités qui existent dans les composants de l'annuaire X.500, autres que le DAP. Par exemple, le contrôle de sécurité, duplication des données entre des sites multiples et utilisation de caractères plus complexes que le simple ASCII.

Les principaux éléments du protocole LDAP sont :

• un protocole permettant d'accéder à l'information contenue dans l'annuaire et définit comment s'établit la communication client-serveur,

• un modèle de données qui définit le type de données contenues dans l'annuaire,

• un modèle de nommage qui définit comment l'information est organisée et référencée, • un modèle fonctionnel qui définit comment on accède à l'information,

• un modèle de sécurité qui définit comment les données et l’accès sont protégés, • un modèle de duplication qui définit comment la base est répartie entre serveurs. • des APIs pour développer des applications clientes,

Un annuaire LDAP est basé sur un modèle de collection d’objets représentant des entrées d’annuaires. Chaque type d’entrées (d’objets) est composé de plusieurs attributs qui servent à décrire l’objet en question. Pour illustrer ce modèle, prenons un objet "personne". L’objet personne est défini par une liste d’attributs facultatifs ou obligatoires.

Des mécanismes de chiffrement comme SSL ou TLS, et d'authentification comme SASL, couplés à des mécanismes de règles d'accès (ou A.C.L. pour Access Control List) gérées par l’annuaire proprement dit, permettent de protéger les transactions et l'accès aux données.

La plupart des logiciels serveurs LDAP proposent également un protocole de communication serveur-serveur. Il permet à plusieurs serveurs d'échanger leur contenu et de le synchroniser ou bien de créer entre eux des liens permettant ainsi de relier des annuaires les uns aux autres.

Aujourd’hui dans la version actuelle du protocole LDAP est la version 3, celle-ci est définit par les standards délivrés par l’IETF [RFC 2251].

Concernant la communication serveur-serveur, le « referral service » est définit par LDAPv3, par contre le « replication service » est encore en cours de normalisation. Des produits du marché l’ont cependant intégré avec leur propre mécanisme en participant et anticipant la parution de la normalisation.

Contrairement à d'autres protocoles d'Internet, comme HTTP, SMTP ou NNTP, le dialogue LDAP ne se fait pas en ASCII mais utilise le format de codage Basic Encoding Rule (BER).

4.2.2. Modèles de données LDAP

LDAP était à l'origine une passerelle d'accès à des annuaires X500. En 95, l'Université du Michigan créa le premier serveur LDAP autonome (standalone LDAP) utilisant sa propre base de données au format de type dbm. Les serveurs LDAP sont conçus pour stocker une grande quantité de données mais de faible volume et pour accéder en lecture très rapidement à celles-ci grâce au modèle hiérarchique.

Le Directory Information Tree

Les données LDAP sont structurées dans une arborescence hiérarchique qu'on peut comparer au système de fichier Unix. Chaque noeud de l'arbre correspond à une entrée de l'annuaire ou directory

service entry (DSE) et au sommet de cette arbre, appelé Directory Information Tree (DIT), se trouve

la racine ou suffixe (fig1). Ce modèle est en fait repris de X500, mais contrairement à ce dernier, conçu pour rendre un service d'annuaire mondial (ce que le DNS fait par exemple pour les noms de machines de l'Internet), l'espace de nommage d'un annuaire LDAP n'est pas inscrit dans un contexte