Mesures et gestion
Fayçal Bennani, Noëmie Simoni
Ecole Nationale Supérieure des Télécommunications 46 rue Barrault,
F-75634 Paris Cedex 13, France.
{faycal.bennani, noemie.simoni}@enst.fr
Antoine Boutignon
SFR - CEGETEL 9 place des Vosges,
F-92400 Courbevoie, France.
antoine.boutignon@cegetel.fr
RÉSUMÉ La gestion efficace de la qualité du service sur Internet devient de plus en plus importante pour les clients et les fournisseurs du service. Cet article présente l'importance des mesures pour la supervision en général et pour la gestion dynamique en particulier. Afin de permettre une vue commune de la QoS de bout-en-bout et de fournir une solution scalable de gestion, nous proposons un framework établi à partir de modèles conceptuels dont l'application combinée à un système distribué permet de mettre en oeuvre une gestion dynamique et flexible de QoS..
MOTS-CLES: métrologie, QoS de bout en bout, gestion flexible, gestion dynamique, système géré et système gérant
ABSTRACT. The efficient management of quality of service on Internet is becoming increasingly important to both customers and service providers. This paper presents the importance of measurements for dynamic management. In order to allow a common view of end to end QoS and to provide a feasible management solution, we propose a framework built from conceptual models which combined-use for a distributed system makes it possible to implement QoS dynamic & flexible management.
KEYWORDS: metrology, end-to-end QoS, flexible management, dynamic management, managed system, managing system.
1. Introduction
Avec la croissance rapide de l'Internet, la prolifération rapide des services de télécommunication et l'apparition de nouvelles applications multimédia avancées, les systèmes de communication se compliquent et sont aujourd’hui multiopérateurs . Ces changements génèrent un réel besoin de gestion de la QoS. Les solutions, pour de tels environnements hétérogènes, reposent aussi bien sur des règles stratégiques (ou des politiques [1, 2, 3]) que tactiques, afin d'assurer la cohérence des décisions de bout en bout.
Mais, la mise en œuvre de n'importe quelle solution de gestion exige une bonne organisation du système de gestion (applications de gestion) et du système géré (composants gérables munis d'agents de gestion et de MIB). En raison de la complexité croissante dans les systèmes répartis [4], Il convient de pouvoir activer les agents situés à des emplacements stratégiques pour que certaines décisions locales puissent être prises aux moments opportuns.
Afin de situer nos travaux sur la gestion de la QoS de bout en bout, nous introduisons brièvement dans la prochaine section (§2) le périmètre de la QoS à travers sa définition, sa mesure et sa gestion. Cette étude nous permet de dégager les défis à résoudre pour la partie dynamique de la gestion de la QoS (§2.3). La partie suivante (§3) présente nos propositions de métrologie et de gestion dans un contexte DiffServ. Et afin d’assurer une mise en œuvre efficace et adaptable, un framework est défini dans la section suivante (§4). Le cadre conceptuel de cette gestion dynamique et flexible de QoS est décrit (§4.1) et son application à l’architecture DiffServ est présentée (§4.2). La conclusion (§5) met en exergue l’importance du modèle informationnel, c’est-à-dire l’importance de l’instrumentation qui répond
«au quoi et au où» de la mesure.
2. Qualité de service: périmètre
La qualité du service (QoS) se réfère à "l'effet collectif de l'exécution de service qui détermine le degré de satisfaction d'un utilisateur du service"[5]. En fait, on peut dire que par opposition au comportement fonctionnel du service, la QoS traduit la partie non fonctionnelle du comportement, conformément au SLA contracté entre l'utilisateur du service et le fournisseur de ce service.
Pour garantir la satisfaction des utilisateurs, le système de gestion doit réussir à mettre en oeuvre les QoSs qui dérivent des différents SLAs. Ceci passe par une maîtrise globale des différents points de vue à partir desquels la QoS peut être évaluée [6]. Pour signer le SLA, qui est l’expression du Contracted-QoS, le fournisseur propose une Offered_ QoS en se basant sur son Capable_ QoS, alors que l'utilisateur demande une Demanded_QoS en se fondant sur sa Desirable_QoS.
Pour évaluer la conformité au SLA, on doit mesurer aussi bien la Provided_QoS du fournisseur que la Perceived_QoS de l'utilisateur. En fonction des périodes et des valeurs des mesures, des règles doivent être appliquées afin d'avoir une gestion efficace appropriée (Table.1.c: Elles sont définies à la phase de conception et mises
à jour quand l'activité est consommée. À l'initialisation des règles stratégiques sont adoptées et des règles tactiques sont appliquées durant l'exécution).
2.1 Mesurer la QoS
Dans les contextes distribués, les applications reposent sur des échanges qui peuvent emprunter plusieurs réseaux. Fournir une QoS de bout à bout exige alors que la QoS soit effective dans tous les composants du système. Pour contrôler la conformité aux SLAs, on a recours à l’agrégation et au mesurage. La QoS doit être mesurée à travers toutes les couches de l’architecture et au niveau de chaque composant impliqué, de bout à bout. Pour permettre la corrélation des mesures et faciliter leur agrégation de bout à bout, il importe de disposer d'un moyen d'évaluation qui soit homogène et générique. Le modèle d'évaluation de QoS présenté dans [7] vise précisément à répondre à ces exigences. Il permet de spécifier les paramètres de QoS selon quatre critères: Disponibilité, Fiabilité, Délai, et Capacité. Ces critères sont génériques et s’instancient à tous les niveaux de visibilité.
Un pré-requis pour mesurer la QoS est une instrumentation (Tableau 1.a) qui identifie, dès la phase de conception, les indicateurs significatifs (métriques) à utiliser pour spécifier et évaluer la QoS. L'instrumentation de la QoS identifie également les événements de référence (quand) dont l'occurrence modifie la valeur d'une métrique [22], ainsi que les points de mesures où les événements de référence sont observés et/ou estimés [22], à l'aide d'outils de mesure (comment).
La spécification d'un critère de QoS exige l'identification de la current_value (valeur en cours) de chaque métrique associée, alors que l'évaluation d'un critère de QoS nécessite de spécifier la threshold_value (valeur seuil) et de superviser (Tableau 1.b) la current_value de chaque métrique associée. Pour évaluer la current_value d'une métrique, la méthode de mesures peut être directe ou indirecte.
Les méthodes de mesure indirectes incluent [21]: i. la projection à partir de mesures plus élémentaires, ii. L'estimation d'un constituant métrique à partir d'un ensemble de mesures plus agrégées, et iii. l'estimation d'une métrique à un instant à partir d'un ensemble de métriques associées, à d'autres instants.
Un point important relatif aux mesures est si la méthode de mesures est intrusive ou pas. Les mesures non-intrusives observent les propriétés du service rendu à un utilisateur donné par des moyens qui n'interfèrent pas avec ce service utilisateur.
Tandis qu'avec une mesure intrusive, il y a une charge supplémentaire pour le système (qui peut varier de manière significative selon les mécanismes de mesure) qui peut modifier son état et les événements de référence qui déclenchent l'évaluation d'une métrique. Cette charge supplémentaire peut être en terme de charge de traitement (CPU) comme celle introduite par les compteurs que nous trouvons aujourd'hui dans les MIBs de chaque élément réseau. Elle peut être également en terme de surcharge CPU et de données spécifiques utilisées pour les mesures, comme lorsque des données de sondage sont injectées dans des réseaux de
paquets. Notons enfin que les flux de gestion liés à la collecte et au traitement des données mesurées ne sont pas pris en compte dans cette distinction.
Pour conclure ce paragraphe, il n'est pas inutile de rappeler que les données de mesures sont habituellement disponibles, pour la gestion, dans des bases de données. Certaines sont standard (MIB II, RMON, M3100), beaucoup sont propriétaires, alors que certaines autres sont souvent des tables constituées et fournies par des instruments de mesure spécifiques.
2.2 Gérer la QoS
Fondamentalement, il y a trois moyens de fournir la QoS dans un système de traitement distribué: le surdimensionnement, la réservation de ressources et la différentiation de services.
Avoir toujours des ressources en réserve est peut être, pour un fournisseur, la solution technique la plus simple pour anticiper des demandes multiples et simultanées. Mais moins évidente est, toutefois, la viabilité économique de ce modèle de surdimensionnement.
Avec les solutions de réservation, par contre, les ressources du fournisseur sont attribuées en fonction de la demande en QoS des utilisateurs et sont sujettes à une politique de gestion.
Alors que dans le modèle de différentiation du service, les demandes des utilisateurs sont classifiées et les ressources du fournisseur sont réparties selon des critères de politiques de gestion des ressources. Les classifications accordent aux utilisateurs des traitements différenciés en fonction de leurs besoins (ou profils) de QoS.
Mais indépendamment du moyen par lequel elle est attribuée, la QoS doit être supervisée et gérée pour assurer qu'elle soit et reste conforme au SLA. La faisabilité de ses fonctions sous-jacentes de supervision et de contrôle dépendent de la pertinence de l'instrumentation de QoS qui a été faite pendant la phase de conception.
Quand ces fonctions de gestion de QoS s’appliquent à l'initialisation (provisionning) ou à la fin de l' activité, la gestion de QoS est considérée être statique (Tableau 1.d; configuration). Un tel mode de gestion rend difficile, sinon impossible, l’adaptation à une évolution ou à un changement quelconque de l'environnement ambiant comme une modification de la demande ou une dégradation de la performance du fournisseur direct ou d'un ou plusieurs de ses fournisseurs intermédiaires. Pour permettre à la Contracted_QoS d'être réalisée de manière continue, la gestion de la QoS doit être dynamique (Table.1.d;
renégociation), c.-à-d. que les fonctions de gestion de QoS doivent être également applicables durant l'exécution de l'activité.
2.3 QoS de bout en bout : notre vision
Pour introduire notre vision (Tableau 1), il est important de considérer la phase de conception d'une activité de télécommunication séparément de sa phase d'exploitation. En effet, l'efficacité des fonctions de gestion qui sont réalisées durant la phase d'exploitation dépend de l’instrumentation de la QoS qui a eu lieu auparavant durant la phase de conception. Par conséquent, la portabilité de la solution dépend du soin apporté aux choix, conceptions et définitions faits pendant la phase de conception.
Concernant la phase d'exploitation, l'approvisionnement de QoS a lieu à l'initialisation de l'activité, alors que la planification de QoS a lieu une fois l'activité consommée. La flexibilité de la première et l'adaptabilité de la dernière sont étroitement liées au niveau de souplesse avec lequel les règles de décision peuvent être adoptées et mises à jour sans affecter le processus de gestion lui-même.
Mais, au delà de ces deux ensembles de fonctions de gestion, nous identifions les fonctions qui s'appliquent durant l'exécution comme étant celles qui posent le plus de défis pour gérer dynamiquement la QoS. C’est entre autre cet aspect dynamique que nous traitons dans la suite de l’article.
Phase d’exploitation Cycle de vie d’une
activité Phase de conception
Initialisation Durant l'exécution Après
Mesures (a)
Métriques Evènements de référence
Points de mesure Outils de mesure
Initialisation des entités
de mesure Collecte des données Synthèse et stockage des données
Supervision (b) Valeurs de conception Valeurs seuils
Valeurs en cours
Valeurs en cours Alarmes
Analyse & planification
Décision (c) Définition des règles stratégiques et tactiques
Adoption de règles stratégiques
Application de règles
tactiques Mise à jour des règles
Commande (d) Identification des paramètres
configurables Configurations
Renegotiations Accord (tunning),
Maintenance
Reconfigurations
Challenges (e) Instrumentation portable de la QoS
Approvisionnement flexible de la QoS
Gestion dynamique de la QoS
Planification adaptable de la QoS
Tableau 1 : Notre vision de la QoS de bout en bout
3 QoS de bout-en-bout DiffServ: gestion dynamique
IN
IN IN
IN
IN E N
C N C N
C N C N
C N IN
E N C N
C N
C N C N
C N
D o m ain A
D o m a in B
D o m ain C
IN : Ingress N o d e C N : C o re N o d e E N : E gress N o d e IU : Interco nnectio n U nit Q B : Q o S B ro ker B M : B ro kers M anger
IN
C N E N
Q B Q B
Q B B M
C N
C N
C N
C N
IU IU
Figure 1: Une organisation en domaines DiffServ pour une gestion dynamique Dans cette section, nous considérons un contexte DiffServ conforme à l'organisation en domaines de gestion que nous avons adoptée dans [6] et qui nous permet de considérer une gestion dynamique. Dans une telle organisation (fig.1), des agents à délégations variables et variées sont placées dans chaque nœud périphérique (BN) ou dorsal (CN), alors qu'un gestionnaire est nécessaire par domaine individuel. Des unités d'interconnexion entre domaines (IU) permettent d'avoir des décisions tactiques afin de réaliser la QoS de bout en bout.
Comme nous venons de le voir dans la section précédente, les mesures sont primordiales pour l'évaluation de la QoS et la pertinence des prises de décisions de gestion. C’est pourquoi, nous allons donc aborder dans la suite de cette section les mesures et la gestion de DiffServ étudiées sur notre plate-forme d'essais DiffServ représentée sur la figure 2.
3.1 Mesurer
Dans DiffServ, le trafic IP est séparé en des classes servies différemment par le réseau. Mesurer la QoS dans un contexte DiffServ revient, donc, à mesurer les QoSs de bout à bout réalisées par chacune des classes supportées.
Quelles sont les métriques pertinentes pour DiffServ ?
Si l'on se réfère à une partie de la recherche qui a été faite pour définir des métriques de QoS pour les réseaux conventionnels IP, nous trouvons le groupe de travail IPPM (IP Performance Metrics) de l'IETF qui a travaillé sur l'identification de métriques pour le service Internet [21] et la recommandation I.380 de l'UIT-T qui définit des paramètres destinés à spécifier et évaluer la performance du transfert de paquets IP [22]. A partir de ces deux travaux, nous avons dressé le Tableau 2 dans
lequel nous associons à nos critères de QoS les métriques et paramètres qui sont pertinentes pour DiffServ, une fois mesurés pour chaque classe de service, c-à-d.
pour chaque DSCP (point de code de DiffServ).
Métriques de performance et de fiabilité IP de l'IETF- IPPM
ENST's QoS criteria
Paramètres de performance IP de l'ITU-T' (I380)
Type-P-Instantaneous-Unidirectional-Connectivity Type-P-Instantaneous-Bidirectional-Connectivity Type-P-Interval-Unidirectional-Connectivity Type-P-Interval-Bidirectional-Connectivity Type-P1-P2-Interval-Temporal-Connectivity
Disponibilité IP service availability
Type-P-One-way-Loss Fiabilité IP Packet Loss Ratio (IPLR)
IP Packet Error Ratio (IPER) Spurious IP packet rate Type-P-Round-trip-Delay
Type-P-One-way-Delay Type-P-One-way-ipdv
Délai IP Packet Transfer Delay (IPTD) IP Packet Delay Variation (IPDV) Capacité IP packet throughput (IPPT)
Octet based IP packet throughput (IPOT) Tableau 2 : Critères et métriques QoS
Où les métriques DiffServ sont - elles pertinentes ?
Ces métriques peuvent être mesurées, par l'intermédiaire d'entités de mesure, pour un service DiffServ de bout en bout, point à point, ou pour des portions du réseau qui fournissent ou contribuent à la fourniture d'un tel service. Du point de vue d'un client, les points de mesure appropriés sont ses interfaces avec chaque BN pour vérifier la conformité avec le SLA, alors que pour le fournisseur il peut être utile aussi d'avoir des points de mesure entre les CNs, et entre CNs et BNs (cf.
fig.2), afin de réagir rapidement.
Comment mesurer les métriques DiffServ?
Les entités de mesures peuvent se baser sur l'approche de sondage du réseau où la performance de bout à bout sur des chemins réseau se mesure en transmettant des paquets de sondage le long du chemin. Les méthodes de sondage conventionnelles sont Ping (Packet INternetwork Groper) et Traceroute, disponibles sur beaucoup de plates-formes. En utilisant les messages ICMP (echo_request et reply), la commande classique Ping peut déterminer si un nœud est actif (connectivité) ainsi que le délai aller-retour d'un paquet. De la même manière, la commande Traceroute utilise des messages ICMP (time_exceeded) pour tracer le chemin et le délai pris par un paquet pour atteindre sa destination. Le sondage réseau peut être largement utilisé dans un environnement réseau multi-constructeurs.
Les entités de mesure peuvent également émuler les flux échangés sur le réseau par des applications du monde réel. Sur une base ordonnancée, la performance du
réseau peut alors être mesurée en termes de temps de réponse, de débit, et de connectivité. En réalisant une mesure active de la performance du réseau, une même application peut émuler à plusieurs reprises une même loi d'échanges réseau sur des intervalles prédéfinis. Grâce à une telle supervision répétable, on peut comparer les mesures prises à différentes dates pour établir des lignes de base, découvrir des anomalies et détecter les tendances de manière pertinente.
IN
CN EN CN
CN CN
CN
LAN1 LAN2
PC1 IPe1 PC2
IPe2
LAN3 Requêtes SNMP
Requêtes SNMP
Serveur SNMP
NOC
Figure 2: Une organisation mono-domaine de DiffServ pour mesurer la QoS D'autres entités de mesures peuvent simplement observer le trafic réel et mesurer les métriques du trafic observé. Nous avons adopté pour nos expérimentations (fig.2), les ip|engines d'Ipanema [23] qui ont l'avantage de permettre des mesures temps-réel non intrusives du trafic réel.
Alors que ces mesures de métriques peuvent rapidement renseigner sur des dérives la QoS de bout à bout, elles ne peuvent pas être d'une grande utilité pour diagnostiquer et localiser avec précision les origines de la dérive. C'est pourquoi nous préconisons également de collecter les informations de performance de chaque élément réseau sur le chemin évalué. Ceci peut être réalisé à l'aide de moniteurs SNMP (Simple Network Management Protocol) qui doivent saisir de manière permanente les valeurs des compteurs intégrées des MIBs attachées à chaque élément réseau. Comme référence, nous donnons dans le Tableau 3 quelques indicateurs standards de MIB II qui peuvent être utiles pour le contexte de DiffServ.
Quand est-il opportun de mesurer les métriques DiffServ?
Quand prendre ces mesures dépend de la manière avec laquelle la gestion est voulue par la politique de gestion. Comme nous visons à réagir durant l'exécution de la communication, l'organisation que nous avons proposée (figure1) permet de réaliser des mesures dans chaque domaine afin d'avoir des réactions dynamiques dans les domaines adjacents suite à la dégradation de QoS.
Critères QoS Niveau de Visibilité
Disponibilité Fiabilité Délai Capacité
DiffServ (draft)
diffServAlgDropPkts diffServAlgDropHCOctets
IP ipInDiscards
ipInDelivers
ipInHdrErrors ipInAddrErrors ipInUnkownProtos ipReasmFails
ipInReceives ipOutRequests
Couche 2
(dépend si Ethernet, Frame relay, ..)
+ couche physique
ifOperStatus ifInDiscards ifOutDiscards
...
ifInErrors ifOutQLen,
etherStatsCollisions
ifInOctets ifOutOctets ifSpeed
ifInOctets ifOutOctets
Equipement (Propriétaire)
busyPer avgBusy
ciscoMemoryPoolUsed ciscoMemoryPoolFree
Tableau 3: Quelques compteurs MIB convenant à superviser DiffServ
3.2 Gestion
Pour gérer dynamiquement la QoS, il faut pouvoir suivre l'activité dans son évolution, de proche en proche et rectifier le comportement quand et où cela est nécessaire. Cependant, la plupart des solutions de gestion actuelles ont une organisation centralisée où un seul MDP (point de décision de gestion) est directement responsable de surveiller et de commander chaque MPE (point d'application de gestion) du système géré. En raison de la surcharge importante qu'elles peuvent introduire sur le trafic global et des retards sous-jacents qui peuvent avoir comme conséquence des décisions obsolètes ou contradictoires, ces organisations centralisées sont peu adaptées pour une gestion dynamique de la QoS.
L'organisation de DiffServ que nous avons adoptée (fig.1) se prête à un mode distribué de la gestion (fig.3) qui est de nature à satisfaire les besoins d'un contexte dynamique. Le système géré (DiffServ) y est, en effet, organisé en domaines autonomes du point de vue de la gestion (et qui peuvent correspondre par exemple aux domaines ou sous-domaines d'un transporteur télécoms) où des DMDPs (Domain Management Decision Points : Points de décision de gestion par domaine) ont une grande autonomie pour surveiller et contrôler la QoS localement. Un MDP global prend en charge les négociations renégociations inter-domaines de la QoS et ajustent les paramètres d'entrée de QoS quand et où cela est nécessaire. Dans les unités d'interconnexion IN (Interconnection Units), nous trouverons des MDEPs (Points de décision et d'application de gestion) qui ont la capacité de prendre et
d'exécuter des décisions en temps réel, puis de notifier leurs actions aux DMDPs.
Correspondants. Ainsi, les décisions tactiques [8] peuvent être confinées aux DMDPs ou aux MDEPs tandis que le MDP peut se focaliser sur des décisions stratégiques.
Managing System
Managed System
BM
Monitoring Adaptation
Notifications
QB
Domain 1 EN QoS parameters
IN QoS parameters
Maintenance Monitoring
Notifications
Domain 2 EN QoS parameters
IN QoS parameters
Notifications
Domain n EN QoS parameters
IN QoS parameters DMDP
MEPMEPMEP MEPMEPMEP MEPMEPMEP
QB
Maintenance Monitoring
DMDP QB
Maintenance Monitoring DMDP MDP MEP: Management Enforcement Point
MDP: Management Decision Point DMDP: Domain Management Decision Point MDEP: Management Decision & Enforcement Point
Centralized management
Managed system MEPMEPMEP MEPMEPMEP
MDP
Monitoring Controls
Managing system
Renegotiation
Renegotiation
Renegotiation Renegotiation
MDEP MDEP
IU IU
Figure 3: Une organisation distribuée de gestion pour une gestion dynamique et scalable de QoS
Dans cette organisation, le fournisseur propose un ensemble de CoSs (Offered_
QoS) en se basant sur son Capable_ QoS (PHBs DiffServ), alors qu’une application utilisatrice demande une Demanded_QoS se basant sur son Desirable_QoS (profil).
Selon le Contracted_QoS émis dans le SLA, on accorde à chaque application une première CoS. Les QBs supervisent et évaluent le Provided_QoS pour chaque CoS (en utilisant par exemple des outils de sondage comme le ping) et communiquent entre eux pour accorder et changer la configuration quand et où cela est nécessaire (b).Le BM, qui est mis au courant de la négociation entre les QBs, compare en permanence la contracted_QoS de chaque application à son perceived_QoS. En cas de non conformité, il peut demander à l'IUs d'attribuer à l'application un CoS plus approprié (b), par la mise à jour des règles de mapping {application - > DSCP}
utilisées dans IUs.
4. Un framework pour la gestion dynamique de la QoS
La mise en œuvre de n'importe quelle solution de gestion exige une bonne synergie entre le système de gestion (applications de gestion) et le système géré (composants gérables munis d'agents de gestion et de MIBs). Pour une gestion de la QoS pertinente, il faut prendre en compte chacune de ses multiples dimensions:
organisationnelle, informationnelle, architecturale, fonctionnelle, et relationnelle.
Pour aider à réaliser cette gestion pertinente, nous avons proposé dans nos travaux antérieures des modèles conceptuels qui sont relatifs, chacun, à une dimension particulière de la gestion de QoS [17]. Le framework de QoS que nous présentons dans cet article (fig. 4) propose une utilisation combinée de ces modèles
conceptuels pour mettre en oeuvre une gestion dynamique pertinente de la QoS dans un système distribué.
4.1 Le framework
Modèle Informationnel : Le modèle “objet géré”
Le socle du framework est constitué par le modèle informationnel , qui modélise les « objets gérés » [6] et qui représente n'importe quel composant. De plus, chaque objet opérationnel intègre la gestion du service qu’il doit rendre. La gestion du service de l’objet est donc intégrée et accessible par une interface dédiée à la gestion (dimension informationnelle).
Dimension Architecturale : Le modèle abstrait de réseau
Dans toutes activités réseau, les objets gérés peuvent être impliqués à différents niveaux de responsabilité. Pour avoir un support commun d'évaluation et de définition des actions de gestion, le modèle abstrait de réseau permet d’abstraire tous les objets gérés, quelque soit leur niveau de visibilité (matériel, réseau, service, application...), suivant trois types d'éléments abstraits de réseau « Nœud, Lien, Réseau ». Un nœud est une représentation générique des capacités de traitement, alors qu'un lien représente une capacité de transfert. Il y a, par ailleurs, autant de niveaux de visibilité que de niveaux possibles de décision de gestion. Un réseau est alors l'ensemble des nœuds et des liens actifs pour un service d’un niveau de visibilité donné [7].
Dimension de communication : Le modèle relationnel
Selon leur degré de responsabilité et afin d'assurer mutuellement le service, les composants distribués interagissent et coopèrent par les relations qui les lient les uns aux autres. En dehors de la relation classique de subordination gestionnaire- agent {MDP - MPE}, le modèle relationnel identifie la relation de coopération de pair-à-pair et la considère comme plus efficace pour la gestion dynamique dans un contexte distribué. Une relation pair-à-pair peut être une relation de gestionnaire- gestionnaire {DMDP/MEP - DMDP/MEP}, qui reflète la coopération entre les différents domaines (fig. 1). C'est cette relation de coopération qui sera utilisée dans notre étude de cas dans la section 4. Mais, il est possible d'avoir également une relation pair-à-pair entre agents pour refléter la coopération des agents délégués {LMDP/MEP - LMDP/MEP}.
Dimension Fonctionnelle - Système géré : Le modèle de réaction
En interagissant avec d’autres composants pour accomplir les tâches de gestion, un objet peut mettre en œuvre différents types de comportements. Le modèle de réaction [6] trace les grandes lignes de quatre comportements possibles de réaction : passif, actif, interactif et proactif. L’assignation des réactions aux objets se fait bien sûr en fonction du problème spécifique à résoudre et du rôle du composant. Telle
situation peut justifier une approche passive dans un domaine alors que dans un autre domaine elle peut exiger une approche proactive.
Dimension Fonctionnelle - Système gérant : Le modèle de coordination
Les composants distribués assurant le service considéré peuvent se répartir sur plusieurs domaines. Assurer la QoS bout à bout exige par conséquent une harmonisation étroite entre ces composants distribués. Le modèle de coordination conduit avec précision le processus coopératif de gestion à travers les différents domaines gérés [15, 16].
Dimension Organisationnelle : Modèle de déploiement “Policy-driven decision”
La gestion dynamique d'un système réparti exige d'avoir des capacités locales de résolution des problèmes pour des réactions rapides. Plus précisément, par son interface de gestion, on peut attribuer à un objet géré un rôle d’agent autonome délégué avec assez d'intelligence et d’informations pour prendre les décisions qui s’imposent [10, 11]. Ceci permet d'avoir un certain nombre de LMDPs distribués (point de décision de gestion locale) pour des réactions plus rapides et flexibles, au lieu de tout faire reposer seulement et rigidement sur un seul MDP (point de décision de gestion).
En résumé, les décisions peuvent être opérationnelles, tactiques ou stratégiques [8], l'organisation générale du modèle de coordination peut déléguer les décisions opérationnelles aux LDPs et les décisions tactiques aux DMDPs afin de soulager le MDP qui applique les décisions stratégiques.
En définissant les politiques de gestion, un objet géré aura un comportement adapté à chaque situation. Ces différents comportements correspondent au statut de l’objet à son interface de gestion.
Le modèle de QoS
Le modèle de QoS est au cœur de notre problématique et donc de notre framework (fig.4). Il impacte toutes les dimensions que nous venons d’évoquer. En effet, les critères et les paramètres de QoS sont consignés dans la dimension informationnelle du modèle de QoS, les niveaux de visibilité de la dimension architecturale sont ceux où des décisions de QoS peuvent être prises, les interactions de la dimension de communication concernent les échanges pour une QoS de bout en bout. Quant au modèle de réaction, il est activé selon le contrat de QoS et le modèle de coordination intervient globalement et relativement au SLA.
Pour récapituler, nous pouvons dire que selon ce cadre, les composants gérés ont la capacité à coopérer selon le modèle abstrait de réseau et les niveaux de visibilité considérés pour la gestion. Chaque objet se comporte selon le type de réaction (modèle de réaction) qui lui a été assigné et le type de relation - horizontale ou la verticale - qui le lie aux composants avec lesquels il interagit (modèle de relation).
L'organisation considérée est harmonisée à travers le modèle de coordination. Pour bien plus de clarté, nous allons appliquer ce framework à l’organisation que nous avons préconisée pour DiffServ (fig.1).
Utilisation combinée des modèles du framework
Abstract network model
Reaction model
Coordination model
QoS model Managed object model
Policy
Informational dimension
Architectural dimension
Communication dimension Relation
model Functional
dimension:
Manager Organizational
dimension
Functional dimension:
Agent
POLICY
Figure 4: Framework pour une gestion dynamique et distribuée de la QoS
4.2 Scénario DiffServ
Après avoir présenté notre framework de QoS dans la section précédente, il serait intéressant d'explorer ses capacités et contributions par l'étude de cas d’une organisation en multi-domaines de DiffServ (fig.1).
Pour faciliter la compréhension, nous considérons que le point de vue de l'utilisateur du réseau est un IP/VPN (réseau privé virtuel) avec différenciation de services. Un service IP/VPN se fonde sur d’une part, la fonctionnalité de VR (routage de VPN) et d’autre part, la fonction IDC (interconnexion de domaine). La différentiation de services dans un domaine DiffServ concerne l'agrégation du trafic (TA), le conditionnement de trafic (TC) et le transfert de proche en proche (PHB).
Ainsi, les composants distribués gérables du système sont VRs, IDCs, TAs, TCs, et PHBs. Le modèle abstrait de réseau de ce contexte est représenté par la figure 5.
Selon le modèle < nœud, lien, réseau > présenté (§4.1), nous voyons que le IP/VPN DiffServ est une ressource de réseau composée de nœuds (VR, IDC) et de liens (lien VPN) du même niveau de visibilité(v). Il se fonde sur les domaines DiffServ, qui sont des réseaux d'un niveau de visibilité inférieur(v-1). Chaque domaine DiffServ, à son tour, se compose de nœuds et de liens de même niveau de visibilité et reposent sur un réseau de niveau de visibilité inférieur(v-2). Nous avons
considéré les composants du domaine DiffServ TA, TC et PHB à des niveaux de visibilité différents pour pouvoir prendre des décisions précises en conformité avec chacune de ces fonctions. Chaque domaine DiffServ (et ses sous-réseaux) se base sur le réseau IP qui a également des sous niveaux que nous n’avons pas développés dans cette étude de cas.
L'application du modèle d'objet géré mène aux objets gérés suivants : Nœuds VR, nœuds IDC, nœuds TA, nœuds TC et nœuds PHB. Notons que les objets gérables appartiennent à différent niveau de visibilité mais peuvent partager le même équipement.
MEP
MEP
MEP DiffServ-based VPNs architecture
DiffServ domain
TC network
TA link TA node
PHB link PHB node
IP bearer network Managed VPN (3)
1
1
DiffServ classifier IDC node VPN link
PHB network
TC link TC node
1
DiffServ meter DiffServ marker
DiffServ scheduler VR node
DiffServ shaper DiffServ dropper
DiffServ re-marker
Managing network
Domain managing-network MDP
DMDP link
Domain managed-network
Bearer network DMDP
MEPs link MDEP
DiffServ prober
Figure 5: Modèle abstrait de réseau pour un service VPN DiffServ Des comportements appropriés doivent être assignés aux objets gérés. Selon le modèle de réaction, le mode « passif » est le comportement par défaut de chaque objet géré. Les nœuds IDC ont un mode plutôt « interactif » car ils interviennent à l'interconnexion de réseaux entre les domaines DiffServ. Ces nœuds comparent sans interruption le « Provided_QoS » au « Contracted_QoS ». Les domaines peuvent avoir un même jeu de CoSs (interconnexion transparente) ou avoir des jeux différents de CoSs (interconnexion non transparente, avec mise en correspondance).
Pour un dynamisme plus efficace, un comportement « proactif » dans des nœuds IDC devrait être évalué. Il pourrait être appliqué à une certaine classe du trafic (temps critique ou priorité élevée) tandis qu'il serait inhibé pour une autre classe du trafic (priorité asynchrone ou basse). De la même manière, un comportement
« actif » peut sembler approprié pour les nœuds TC ou TA.
Un MDP global est nécessaire pour les décisions stratégiques du service VPN.
En ce qui concerne cette entité, les nœuds IDC sont impliqués dans la relation {MDP - MPE}, alors que l'interaction entre deux nœuds IDC est une relation de coopération {DMDP/MEP - DMDP/MEP}.
L’instantiation du modèle informationnel de QoS pour chaque élément, de chaque niveau de visibilité, conformément au modèle abstrait de réseau (fig.5), rend disponible l'information pertinente qui évalue le « Provided_QoS » et permet de prendre des décisions de QoS aux bons endroits et aux bons moments. Par exemple, pour mettre à jour le Provided_QoS conformément au « Contracted_QoS », le MDP peut (re-)déclencher le modèle de coordination pour accorder le processus coopératif de gestion entre les domaines gérés.
5. Conclusion
Sur le marché dérégulé et compétitif d'aujourd'hui, les opérateurs de télécommunication et les ISPs doivent pouvoir définir leurs différentes stratégies de gestion et ajuster leurs décisions individuelles. Pour permettre la mise en œuvre de la QoS de bout à bout pour de tels environnements, le framework de QoS proposé dans cet article fournit des capacités de structuration et de gestion répartie, aussi bien pour s'adapter avec souplesse aux changements d’environnement (flexibilité) que pour être efficace. Par son modèle d'objets gérés et son modèle abstrait de réseau, il permet d’organiser le système de gestion en domaines distribués. La gestion dynamique de la QoS est assurée par la distribution des tâches et des décisions de gestion sur tous les nœuds des domaines du système. Son modèle relationnel facilite l'extensibilité et la coopération de pair-à-pair, alors que le modèle de réaction facilite l'adaptabilité de gestion et la personnalisation en contrôlant les comportements de gestion des composants gérés. La cohérence des réactions est assurée par le modèle de coordination et la pertinence de l'information repose sur le modèle informationnel de QoS et la métrologie mise en œuvre.
6. Bibliographie
[1]. Sloman M., "Policy Driven Management for Distributed Systems", Plenum Press Journal of Network and Systems Management, vol. 2, no. 4, December 1994.
[2]. Alpers B., Plansky H., "Concepts and Application of Policy-Based Management", International Symposium on Integrated Network Management (ISINM), Santa Barbara, 1995.
[3]. Sloman M., "Policy agents: licensed to manage", http://www-dse.doc.ic.ac.uk/mss/policy- agent/index.html, June 1998.
[4]. Sloman M., "Network and distributed systems management", Addison-Wesley, 1994.
[5]. ITU-T Recommendation E.800, "Terms and definitions related to quality of service and network performance including dependability", August 1994.
[6]. Bennani F., Simoni N., "An asset for QoS dynamic management organization: application to the DiffServ Context", to appear in the proceedings of the 5th World Multi-Conference on Systemics, Cybernetics and Informatics (SCI 2001), Orlando, Florida, July 2001.
[7]. Simoni N., Znaty S., "Network and service management", InterEditions, Paris, 1997.
[8]. Pernet J-F, Saad N. and Simoni N. "Tactical Network Management for preserving the QoS", IEEE Milcom'98, Bedford MA, USA, October 1998.
[9]. Arsenis S., Perdigues N., Simoni N., "Distributed Applications and Networks Integration:
from Modelling to Implementation", TINA 95, Melbourne, Australia, February 1995.
[10]. Glodszmidt G., Yechiam Yemini, "Delegated Agents for Network Management", IEEE Communications Magazine, March 1998.
[11]. Wies R., Mountzia M. A. and Steenekamp P., "A practical approach towards a distributed and flexible realization of policies using intelligent agents", in proceedings of the 8th IFIP/IEEE International Workshop on Distributed Systems: Operations and management, October 1997.
[12]. Black U., "Network Management Standards", McGrae-Hill Inc., 1994.
[13]. Case J.D., Fedor M., Schoffstall M.L., Davin C., "Simple Network Management Protocol (SNMP)", IETF RFC 1157, May 1990.
[14]. Warrier U.S., Besaw L., LaBarre L., Handspicker B.D., "Common Management Information Services and Protocols for the Internet (CMOT and CMIP)", IETF RFC 1189, 1990.
[15]. Zhang J., Simoni N., "Distributed service management for Intelligent Network", International Conference on Computer Communication (ICCC'99), Tokyo, September 1999.
[16]. Zhang J., "Tools for distributed and cooperative service management: Application to the Intelligent Network", Ph.D. dissertation, Ecole Nationale Supérieure des Télécommunications (ENST), France, 1999.
[17]. Znaty S., "The Quality of Service of multinetworks: from the model to its implementation", Ph.D. dissertation, Ecole Nationale Supérieure des Télécommunications (ENST), France, 1993.
[18] Arsenis S., Simoni N., Znaty S.. "Distributed System Management treatment: Toward the self-management ", Globecom' 96, London Uk, novembre 1996.
[19]. IETF DiffServ working group, http://www.ietf.org/html.charters/diffserv-charter.html.
[20]. Cherkaoui O., Obaid A., Serhrouchni A., and Simoni N., "QoS Metrics tool using management by delegation," in proc. IEEE/IFIP 1998 Network Operations And Management Symposium, New Orleans, 1998, vol. 3, pp. 836-839.
[21]. ITU-R Recommendation I.380: Internet Protocol Data Communication Service – IP Packet Transfer and Availability Performance Parameters. 1998.
[22] Paxon V., et al.: "Framework for IP Performance Metrics". RFC 2330.
[23]. http://www.ipanematech.com/products.html
