Une plate-forme de supervision intégrée du Multicast

Une plate-forme de supervision intégrée du Multicast H. Sallay, R. State, O. Festor LORIA-INRIA Lorraine 615 rue du Jardin Botanique 54602 Villers-lès-Nancy, France {Hassen.Sallay, Radu.State, Olivier.Festor}@loria.fr RÉSUMÉ Si les services multicast deviennent de plus en plus attrayants, leur déploiement commercial actuel est ralenti pour plusieurs raisons. L une des raisons est le manque de solutions de gestion intégrées pour l ensemble de composants participant aux différents niveaux de ces services. D excellents outils autonomes existent aujourd'hui sur le marché et ils représentent de bons candidats à l intégration. Ces composants, s ils sont intégrés et pilotés dans une plate-forme de gestion standard, couvrent la plupart des fonctions de gestion de services multicast. Dans ce papier, nous proposons une architecture d intégration de deux outils de gestion multicast. Cette intégration vise à combiner la supervision de la topologie, la simulation des scénarios du test et la supervision de trafic réel sur le réseau. L architecture proposée est implantée dans un environnement Java. Elle est utilisée pour le contrôle du niveau du service et la collecte de données de gestion. ABSTRACT. While multicast services are becoming very attractive, their large deployment and commercial use is currently slowed down partly due to the lack of integrated management solutions for the components that participate to the operation of these services at various levels. Excellent standalone components exist today and are good candidates for the integration. Joined and interfaced with standard management platforms, they cover most of the functions retaled to multicast service monitoring. In this paper we present the resulting architecture of one integration effort which combines two multicast management tools for topology monitoring, pre-event testing and in-situ monitoring. The proposed architecture is used for service level monitoring and data collection. MOTS-CLÉS : Multicast IP, Supervision, MRM JMX, Gestion de niveaux de services(slm). KEYWORDS: IP Multicast, Monitoring, MRM, JMX, Service Level Management.

2 GRES, Décembre 2001, Marrakech. 1. Introduction Les services multicast acquièrent de plus en plus d importance dans l Internet. Initiallement déployés dans le Mbone à travers des routeurs multicast interconnectés par des tunnels, les protocoles multicast sont maintenant déployés dans la plupart de routeurs commercialisés et supportent une variété d applications (travail coopératif, téléconference, télééducation ). La spécification de nouveaux protocoles tels que PIM-SSM (Protocol Independent Multicast Single Source Mode) et EXPRESS (EXPlicitly Requested Single-Source Multicast) [29,30] plus simples qui permettent le passage à l échelle et englobant une bonne gamme d applications, va sans doute accélerer le déploiement du multicast. Cependent, une bonne gestion de ces services s impose. En effet, pour commercialiser et déployer à grande échelle un service multicast, des solutions de gestion intégrées capables de garantir un niveau donné de qualité de service doivent être fournies. D excellents composants autonomes existent aujourd'hui sur le marché et ils représentent de bons candidats pour une bonne intégration. Des utilitaires tels que Mrinfo, Mtrace, Mhealth offrent des fonctionnalités intéressantes pour la gestion du multicast, mais ils restent spécifiques et incomplets pour une gestion globale d un service multicast. Un effort récent tentant de combler ces insuffisances a émergé avec MRM (Multicast Reachability Monitor) qui définit une architecture distribuée ainsi qu un protocole d échange d informations entre ses composants pour générer du test et superviser les communications multicast. D autres part, opérer dans un environnement standard de gestion s avère nécessaire. En effet, la possibilité d utiliser différentes technologies de gestion (SNMP, WBEM ) et la capacité de présenter diverses données de supervision par la même interface facilite énormément les tâches de gestion. Proposer une architecture de gestion qui intègre ces utilitaires et les pilote dans une plate-forme de gestion standard est l objet de nos travaux. La plate-forme de gestion standard visée couvrira la plupart des fonctions de gestion de services multicast. Ce papier s organise comme suit : la section 2 résume l ensemble des approches existantes pour la gestion multicast. La section 3 présente notre architecture de gestion pour l intégration et détaille l ensemble de ses composants. Dans la section 4, nous détaillerons les aspects de l implantation. Une conclusion et quelques perspectives terminent la contribution. 2. Etat de l art sur les approches existantes pour la gestion du multicast Plusieurs approches pour la supervision des communications multicast ont été définies. Chaque approche vise un ensemble des fonctionnalités particulières de la gestion. De ce fait, les utilitaires existants sur le marché offrent des fonctionnalités intéressantes mais restent encore incomplets. Des travaux au sein de la communauté ont été développés pour combler ces insuffisances. MRM (Multicast Reachability

Une plate-forme de supervision intégrée du Multicast 3 Monitor) [1] qui définit une architecture distribuée ainsi qu un protocole d échange d informations entre les composants de gestion pour permettre du test et la supervision de communications multicast nous intéresse particulièrement. Les fonctions visées sont la mesure de disponibilité, la mesure de qualité de chemin et la détection/résolution de fautes. L architecture MRM comporte 2 composants de base : le superviseur et les agents. Le superviseur est une entité de supervision depuis laquelle un opérateur peut configurer des agents distants et répartis à travers le réseau pour effectuer des mesures et des tests sur une session multicast. Le superviseur (Manager) a pour objectif de permettre à un administrateur de configurer des tests, de collecter les résultats et de les présenter sur une console. Un superviseur est localisé sur une station de travail. Un agent peut-être localisé sur une station ou sur un routeur du réseau. Ces agents peuvent être de deux types : Emetteur ou Récepteur de données de tests. Les agents sont soit des sources (Test Source TS), soit des puits (Test Receiver TR) de trafic de test. Une source de trafic génère du trafic multicast de test suivant un scénario fourni par le superviseur. Un puit intercepte le trafic émis par une source, collecte des statistiques sur ce trafic et envoie des rapports au superviseur. Le protocole d échange se base sur l envoi et la réception de requêtes entre le superviseur et les agents (TR,TS). Le TSR (Test Sender Request) indique au TS comment il devrait produire les paquets du test. Le TRR (Test Receiver Request) indique au TR comment il devrait rassembler les données reçues. Enfin, le superviseur MRM transmet périodiquement des messages beacon pour annoncer sa présence à tous les agents du test MRM. Si MRM est aujourd hui principalement utilisé pour du test, son utilisation pour de la supervision de flux opérationnels est parfaitement possible. De plus, il est flexible et s intègre facilement avec d autres outils de gestion multicast. Malheureusement, ce n est pas fait pour le moment. Plusieurs autres approches considèrent la supervision des services multicast. Certaines d'entre elles comme Mhealth [9], se basent sur RTP (Real Time Protocol) pour la collecte des données de multicast. En fait, ces solutions de supervision utilisent RTCP (Real Time Control Protocol) avec RTP pour s informer sur les abonnés à un ou plusieurs groupes multicast. Msessmon [37], Mlisten[36], et RTPMon[5,37] sont des exemples typiques de cette famille d approches. Mtrace [17] est la version multicast de l'utilitaire traceroute. Il est utilisé pour construire l arbre topologique du multicast. En effet, il trace le chemin de différents récepteurs en amont vers la source en se basant sur les routeurs qui répondent aux requêtes Mtrace. Bien que Mtrace soit très utile, il a plusieurs limites. En effet, une telle approche n est pas vraiment adéquate quand une même session est supervisée par plusieurs outils Mhealth [7]. Une deuxième limite, est la surcharge de routeurs se trouvant sur le chemin vers la source et qui doivent répondre à toutes les requêtes concernant tous les récepteurs. Une gestion de fautes distribuée pour le multicast est proposée dans [7,8]. Dans cette approche, des entités logicielle dites observateurs (Watchers) contrôlent, pour

4 GRES, Décembre 2001, Marrakech. chaque session, leur connectivité avec la source. L avantage de l approche en supervision consiste à ne contrôler qu une seule fois les liens communs à plusieurs observateurs. Cette approche est efficace dans le sens où elle génère moins de trafic de gestion et évite la surcharge des routeurs dans le réseau. D autres approches plus orientées vers la gestion de configuration existent dans la communauté. Mrinfo [5] peut déterminer l'ensemble des tunnels et leurs états pour un routeur particulier. L'utilisation de SNMP dans le contexte de supervision du multicast peut être faite par plusieurs outils. Mstat [5] permet de superviser un seul routeur tandis que Mview [5] peut visualiser la topologie du MBONE et fournir quelques informations de performance. Nous citons aussi un autre outil dit MMON (Multicast Management Tool) [38] qui constitue une partie intégrante du gestionnaire de réseau HPOpenView. Cet outil utilise à la fois Mrinfo et SNMP pour découvrir la topologie d une session multicast dans un domaine donné. D autres outils tel que Mantra [15] permettent de collecter les informations concernant les grands groupes du multicast. Cela est fait en utilisant des scripts d invocation à distance pour s informer sur les sessions actives, les abonnés, les statistiques de groupe et sur le routage multicast. Les approches mentionnées ci-dessus supposent toutes que l accès (SNMP et/ou IGMP) aux équipements réseau est possible. Une méthode sophistiquée basée sur un estimateur de maximum de vraisemblance a été développée pour être utilisée dans un contexte où l'accès direct est impossible. Un tel scénario peut se produire quand le trafic de multicast passe par un réseau privé. L hypothèse initiale est que seule la mesure (perte de paquet et délai de variation) entre les points d entrée et de sortie du segment privé est disponible. Les trois problèmes qui se posent sont comment estimer la topologie sou-jacente [10, 13], les probabilités de perte sur les différents liens [11] et les délais de transmission de paquets pour des liens particuliers [12]. Ce type d approche est développé dans le projet (MINC) [16] au sein de AT&T visant à insérer des sondes du trafic reportant l état du réseau. 3. Architecture de supervision Dans cette section, nous proposons une architecture d intégration pour les outils de gestion multicast. La plate-forme développée couvre un ensemble de fonctionnalités nécessaires pour la gestion des services multicast par l intégration de différents outils de gestion du multicast complémentaires. Cette intégration vise à combiner la découverte de la topologie, la simulation de scénarios de test et la supervision de trafic réel sur le réseau. De plus, la plate-forme développée présente une architecture distribuée accessible par les différentes technologies de gestion existantes sur le marché telles que SNMP, WBEM. La plate-forme peut être utilisée pour la collecte des données de gestion pour le contrôle du niveau du service dans le contexte du SLM.

Une plate-forme de supervision intégrée du Multicast 5 L architecture de gestion proposée est une architecture distribuée qui intègre différents composants de gestion multicast. En effet, l'architecture fonctionnelle de la plate-forme comporte trois composants offrant trois principaux services : un service de topologie, un service de supervision et un service de présentation des données de supervision (voir Figure 1). La plate-forme permet à un administrateur de définir ses jeux de test à la volée. Cette définition inclue des schémas de tests prédéfinis ainsi que des schémas de tests à la volée. Ces tests sont en fait des instances des sessions test de MRM. Le service de présentation prend la forme d'une interface graphique. Cette interface offre une vue intégrée sur la configuration de multicast et la topologie sous-jacente du réseau. Les informations de supervision du multicast sont définies comme étant un ensemble d'informations statiques liées à la configuration de routage du multicast et d'un ensemble d informations dynamiques associées au trafic multicast. Les informations statiques sont fournies par le service de topologie. Les informations dynamiques sont fournies par l entité appelée MrmDomainManager. Nous ne considérons que la tâche de supervision d un domaine administratif en ignorant pour le moment la gestion dans un environnement multi-domaines. Pour des raisons d'efficacité, ce domaine peut être divisé en plusieurs sous-domaines, appelés domaines MRM. Chaque domaine MRM est localement contrôlé par un agent MRM. Figure 1. Architecture de supervision

6 GRES, Décembre 2001, Marrakech. Toutes les entités qui réalisent les différentes fonctions de la plate-forme peuvent être distribuées à travers le réseau. 3.1. Le modèle de gestion MRM Le modèle d information que nous détaillons dans cette section, est une abstraction du modèle MRM qui définit l'interface de lancement des opérations MRM. Il présente plusieurs avantages et répond à notre objectif de développer une plate-forme distribuée pilotée par différentes technologies standards. Ce modèle offre la possibilité de représenter et de gérer des sessions couvrant plusieurs régions du réseau (sous-domaines MRM) dont chacune est sous le contrôle d un Agent MRM. De plus, son implantation dans une infrastructure logicielle de type JMX ou WBEM constitue un second avantage majeur dans le sens où cette implantation garantit l ouverture de MRM aux mondes standards de la gestion. La figure 2 comporte ce modèle d'information de gestion avec ses différents composants. La classe de MRMDomainManager fournit les points d accès à l interface de gestion responsable de la configuration de l ensemble de récepteurs et de sources de multicast. Un test est représenté par la classe Sessions. Toutes les sessions sont incluses dans la classe MRMDomainManager. Cette dernière fournit une interface de programmation (API) qui permet d ajouter/supprimer une session et de lancer/terminer une session. Par exemple les méthodes adddomainsessions() / deletesession() permettent de créer/ajouter ou supprimer une session dans un ou plusieurs domaines MRM. Chaque session définit une configuration pour la session de test MRM. Une configuration indiquera les sources de trafic test, les puits et tous les paramètres du scénario du test. La classe Session est caractérisée par l adresse IP multicast utilisée et un état (active, suspendue, terminée) qui peut être consulté et/ou modifié. Son interface permet les opérations suivantes : ajouter ou supprimer un TS/TR, lister les TSs/TRs actifs, configurer le trafic du test multicast, lancer/arrêter un test.

Une plate-forme de supervision intégrée du Multicast 7 Figure 2. Modèle d information de pilotage de sessions Cette classe est particulièrement importante parce qu elle représente plusieurs classes MRMAgent qui gèrent conjointement une communication multicast. Ainsi, une session multicast couvrant plusieurs régions du réseau et dont chacune est sous le contrôle d un Agent MRM, peut être représentée par ce modèle d information. Chaque Session est associée (indirectement via la classe MRMAgent) à une liste de TestProcess. Ce dernier peut être utilisé pour simuler une source ou un puits. La configuration d une session consiste à une spécification d une liste des MRMAgent, TestProcess, leurs rôles, l adresse IP de groupe multicast, la durée de la session, le temps start-up du test et la fréquence de génération des rapports de gestion. Par exemple : SetTestSenders() et GetTestReceivers() vont configurer et collecter respectivement les états des sources et des puits. Pour collecter et analyser les informations, les méthodes GetFaultStatistics() et displayreport() sont utilisées.

8 GRES, Décembre 2001, Marrakech. La classe MRMAgent représente l agent responsable d'une région spécifique de réseau. Elle fournit une interface pour les différentes applications agissant en tant que TestSenders et TestReceivers. Les opérations pour lancer un test sont les suivantes : 1. l opération starttest(asession) est invoquée dans MRMDomainManager, 2. pour l instance ASession de Session, tous les Agents MRM sont recherchés, 3. pour chaque Agent, la liste de TestSenders et TestReceivers associés est obtenue, 4. l opération startmrmagent est appelée pour chaque objet de la liste obtenue précédemment. Les rapports sont modélisés par la classe Report. Deux types de spécialisations sont définies pour cette classe. La classe Sessionreport contient l état de session, son évolution dans le temps, le pourcentage des pannes. Le Faultreport contient les informations sur les notifications des fautes et des pannes. 3.2. Le gestionnaire de topologie La vue globale du réseau et de l'arbre de multicast est maintenue par le gestionnaire de topologie. Ceci est basé sur un modèle réseau représentant une vue logique des ressources du réseau. Plusieurs modèles réseau sont déjà définis dans [23], [24], [25]. Pour superviser la communication multicast, nous avons retenu un modèle simplifié. Celui-ci est donné dans la figure 3 est utilisé. Nous avons décidé de garder le modèle aussi simple que possible afin de permettre son utilisation dans un environnement dynamique, laissant cependant assez de flexibilité pour modéliser un arbre multicast. À un premier niveau d'abstraction, un arbre de multicast est vu comme un LayerTrail. Les membres de cet arbre sont modélisés par la classe nwttp(network Trail Termination Point). Les paramètres de la classe LayerTrail sont spécifiques à un groupe particulier de multicast, comme l'adresse IP multicast par exemple. Le nwttp renferme les adresses IP des différents membres. À un deuxième niveau d abstraction, nous pouvons décomposer l arbre multicast sur la topologie du réseau. À ce niveau nous recherchons trois classes principales : la classe LC représente un arbre particulier de multicast situé entre deux routeurs adjacents. Elle est délimitée par deux nwctp(network connection termination point).

Une plate-forme de supervision intégrée du Multicast 9 la classe nwctp est utilisée pour représenter l'adresse réseau utilisée par un routeur expédiant les paquets multicast via une interface donnée. la classe SNC(subnetwork connection class) représente, pour un routeur de l arbre, la liste des routeurs et interfaces destinataires du trafic reçu par celui-ci. Bien que cette classe soit plus utile dans un réseau orienté connexion, nous l'avons maintenue dans le modèle pour des raisons de simplicité. Elle nous permet de réutiliser le modèle d'information que nous avons défini dans [6] sans y introduire de changements. Au troisième niveau d'abstraction on s intéresse au réseau physique. À ce niveau, nous modélisons les routeurs et les liens entre eux. Un routeur est représenté par la classe Subnetwork. Les liens physiques sont modélisés par la classe Link. Les attributs typiques de la classe Subnetwork sont hostname et location. Les attributs de la classe Link sont liés à la capacité physique du lien. Les interfaces délimitant un objet Link, sont modélisées par la classe LinkTP(Link TerminationPoint). Un aspect important du modèle réseau proposé est l'utilisation des stéréotypes. Sans entrer dans trop de détails, des stéréotypes sont employés afin d'exprimer les contraintes inhérentes aux communications multicast opérationnelles. Par exemple, un LayerTrail est décomposé en SNC et LC. Cette décomposition assure que le modèle instancié est sans cycle et que ses propriétés de connectivité sont entièrement valides. Ces propriétés sont exprimées en termes d objets et d associations. Nous exprimons ces dernières contraintes par OCL(Object Constrained Language) [26], le compagnon officiel UML proposé par l OMG [27]. Un ensemble de contraintes concernant plusieurs classes sont associées à un stéréotype. Ces stéréotypes indiquent le rôle individuel d une classe en respectant une certaine décomposition. Par exemple, un LayerTrail est l'entité qui est décomposée (un arbre), tandis que ses nœuds sont donnés par les objets de type SNC. Les bords (edges) de l'arbre multicast sont représentés par des objets LC. Des associations liant ces bords aux nœuds (entrant, sortant) sont ajoutées pour avoir un modèle complet et robuste. L utilisation d OCL permet d automatiser l'utilisation des outils qui vérifient, au cours de l exécution, que toutes les contraintes sont satisfaites.

10 GRES, Décembre 2001, Marrakech. Figure 3. Modèle d information réseau 3.3. Gestionnaire de tests Le TestManager est employé pour configurer les éléments TR et TS pour une session de test. Il se base sur un répertoire LDAP [20] utilisé comme référentiel pour les informations de configuration. Les avantages de l utilisation des services de

Une plate-forme de supervision intégrée du Multicast 11 répertoire LDAP pour le stockage des données réseau sont déjà adressés par l'approche DEN [22]. Dans notre cas, nous avons traduit les caractéristiques de la configuration de notre modèle d'information dans un schéma LDAP permettant à l annuaire de stocker les données de configuration d une session de test. En plus de l'information de configuration, nous avons également traduit les rapports FaultReport et SessionReport pour pouvoir stocker dans le répertoire les rapport émis par les Agents MRM. Figure 4. Arbre d information LDAP En se basant sur notre schéma LDAP, chaque configuration de test MRM est stockée dans l arbre de l annuaire (DIT : Directory Information Tree) (voir figure 5). Les informations de configuration de session sont alors récupérées à partir du DIT par chaque gestionnaire de domaine MRM. Cela se fait via un API Java que nous avons développé au dessus de l interface JNDI (Java Naming and Directory Interface). Le DIT est également consulté par chaque processus TR pour stocker les FaultReport.

12 GRES, Décembre 2001, Marrakech. 4. Implantation Nous avons retenu l architecture distribuée JMX [19] pour l implantation de notre plate-forme de gestion. En fait, la technologie JMX présente une bonne approche pour la définition des interfaces standards pour ces plates-formes de gestion distribuées. De plus, JMX a l avantage d être à la fois simple et flexible dans le sens où elle s adapte facilement aux nouvelles technologies de gestion. Ainsi, tous les composants (Agent MRM, gestionnaire MRM, gestionnaire de topologie) ont été développés en JMX. Tous les objets ont été définis par des MBeans et les services communiquent avec l'application de gestion en utilisant les appels de méthodes à distance RMI Java (Remote Method Interface) [35]. D autre part, nous utilisons deux outils pour instancier et mettre à jour le modèle réseau. Le premier est l outil Mrinfo [5] qui permet de récupérer la configuration d'un routeur multicast donné (évidemment, ceci ne peut être fait que si ce routeur répond au message ASK_NEIGHBORS de IGMP). Le deuxième outil est Mtrace [5] qui permet de tracer un chemin d un récepteur à une source. De son coté, l'agent MRM établit et met à jour le modèle d'information réseau par l'invocation de ces deux utilitaires. Cette invocation est faite en utilisant du code natif et c est le seul endroit dans l'architecture logicielle n'étant pas en Java. Un copie d écran de l interface de gestion de la plate-forme de gestion est donné dans la figure 5. L interface graphique est une application Java développé avec le toolkit graphiques Koala [14] pour représenter la topologie et les communications multicast dans un domaine MRM. La région (1) du haut à gauche montre les informations statiques de multicast obtenues à partir des tables de routage multicast. L'affichage de ces informations est fait par plusieurs vues. Dans la figure, trois vues sont définies couvrant les différent zones de la carte topologique à différentes échelles de grandeur. Ceci permet de zoomer dans le cas où la topologie du réseau est dense ou pour se concentrer sur un détail nécessaire sans refaire en entier la carte. La figure 5 montre la topologie du réseau qui se trouve à proximité immédiate de notre réseau de campus. La région (2) du haut à droite de la figure 5, est une interface graphique simple pour l outil Mtrace. Finalement, le composant utilisé pour configurer un MRM Domain/MRM Agent est montré dans la troisième région (3) (bas au centre). Le gestionnaire utilise l un ou l autre interface pour lancer ces actions et collecter les informations de gestion.

Une plate-forme de supervision intégrée du Multicast 13 Figure 5. Interface du gestionnaire 5. Conclusion Les services multicast sont parmi les services les plus importants de l Internet de futur. Etre capable de gérer ces services au niveau du réseau et au niveau de service reste un défi majeur de la communauté de gestion. Pour établir une architecture d une gestion intégrée, nous avons proposé l'intégration de MRM

14 GRES, Décembre 2001, Marrakech. (Management Reachibility Monitor) dans une plate -forme standard de gestion du multicast. Une passerelle permettant de piloter les agents MRM et les sessions de test depuis une plate-forme standard est nécessiare. Pour ce faire, nous avons proposé un modèle de gestion pour la configuration et la collecte des données de supervision dans un environnement MRM multi-domaines. Les tests et la supervision de service ont été intégrés dans notre plate-forme de gestion permettant ainsi une configuration plus facile des nœuds du réseau et des processus MRM. Tous les composants sont développés en Java en utilisant la technologie JMX et sont employés pour superviser les activités de multicast dans notre laboratoire. La plate-forme proposée représente un premier effort d'intégration pour la supervision du multicast. Nous étudions actuellement l'intégration d autres composants supplémentaires dans la plate-forme. Les points d intérêts seront : l'évolution de notre modèle réseau vers les modèles réseau CIM; l'extension de MRM pour pouvoir assurer une meilleure satisfaction pour l'utilisateur, c.-à-d. l étendre avec des algorithmes qui évaluent le niveau de satisfaction de l utilisateur. Nous avons déjà proposé un algorithme dans ce context pour le cas de la transmission vidéo multicast [34] et enfin, la transition à IPv6 et l'influence des protocoles tels que MLD [32] ou REUNITE [33] pour la gestion des sessions multicast sont également des points d'intérêt pour nos futures travaux. 6. References [1] D. Farinacci, K. Almeroth, L. Wei. Internet Draft : Multicast Reachability Monitor MRM, October 1999. [2] L. Wei, K. Almeroth. Internet Draft : Justification for and use of the Multicast Routing Monitor (MRM) Protocol, August 1999. [3] Sun microsystems. White paper : Java Management Extentions : Dynamic management for the service age, June 1999. [4] K. Sarac, K. Almeroth. End host implementation of MRM. [5] K. Sarac. and K. Almeroth. Supporting Multicast Deployment Efforts: A Survey of Tools for Multicast Monitoring., Journal of High Speed Networking--Special Issue on Management of Multimedia Networking. 2001. [6] R. State, O. Festor and Nataf. Managing concurrent QoS assured Multicast sessions using a Programmable Network Architecture, 11th IFIP/IEEE International Workshop on Distributed Systems: Operations and Management (DSOM 2000), Austin TX, December 2000, Springer LNCS [7] Anoop Reddy, Deborah Estrin, Ramesh Govindan. Fault Management in Multicast Trees, ACM SIGCOMM, Stockholm, Sweden, August 2000. [8] Anoop Reddy, Deborah Estrin, Ramesh Govindan. Large Scale Fault Isolation. IEEE Journal on Selected Areas in Communications, special issue on Network Management, vol. 18, no. 5, 2000.

Une plate-forme de supervision intégrée du Multicast 15 [9] Makosfske, K. Almeroth. MHealth. A Real time Multicast tree visualization and monitoring tool. Proc. NOSSDAV 99. [10] R.Caceres, N.G. Duffield, J. Horowitz, F. Lo Presti, D. Towsley. Loss-based Inference of Multicast Network Topology. CDC'99 [11] R.Caceres, N.G. Duffield, J. Horowitz, D. Towsley. Multicast-Based Inference of Network Internal Loss Characteristics. IEEE Transactions on Information Theory. [12] N.G. Duffield, F. Lo. Presti. Multicast Inference of packet delay variation at interior network links. In Proc. IEEE INFOCOM 2000. [13] S. Ratnasamy, S. McCanne. Inference of Multicast Routing Trees and Bottleneck Bandwidth using End-to-end Measurements. In Proc. IEEE INFOCOM 1999. [14] Koala Graphics. www.dyade.fr. [15] P. Rajvaidya, Almeroth, K. A Router-Based Technique for Monitoring the Next- Generation of Internet Multicast Protocols, International Conference on Parallel Processing, 2001. [16] A. Adams, T. Bu, R. Cáceres, N.G. Duffield, T. Friedman, J. Horowitz, F. Lo Presti, S.B. Moon, V. Paxson, D. Towsley, The Use of End-to-End Multicast Measurements for Characterizing Internal Network Behavior, IEEE Communications Magazine, to appear [17] Fenner, W., Casner S. A traceroute facility for IP Multicast, <draft-ietf-idmrtraceroute-ipm-07.txt>, July 2001. [18] J. Walz, Multicast Monitoring Current Usage and a New Hierarchical Protocol, Master Thesis, Dept. of Computer Science, University of Massachusetts, February 2001. [19] Laurent Andrey, Olivier Festor, Emmanuel Nataf, Radu State. JTMN: A Java-based TMN Development and Experimentation Environment IEEE Journal on Selected Areas in Communications,Vol 18., No. 5., May 2000 [20] T. Howes, M. Smith and G.S. Good. Understanding and deploying LDAP directory services. New Riders 2001. [21] J. Strassner. Directory Enabled Networks. Macmillan Technical Publishing, 1999. [22] Deployment Guide. Netscape Directory Server (v 4.1). http://home.netscape.com/eng/server/directory/4.1/pdf/deploy.pdf [23] C.-C. Shen and J. Y. Wei, Network-Level Information Models for Integrated ATM/SONET/WDM Management, IEEE/IFIP 1998 Network Operations and Management Symposium, New Orleans, USA, 1998. [24] Network Resource Information Model. TINA-C, 1997. [25] ITU-T, Generic Network Information Model. Recommendation M-3100 : ITU-T, 1992. [26] J. Warmer and A. Kleppe. The Object Constraint Language: Precise Modeling with UML, Addison-Wesley, 1998. [28] J. Rumbaugh, I. Jacobson and G. Booch. The Unified Modeling Language Reference Manual, Addison-Wesley, 1998.

16 GRES, Décembre 2001, Marrakech. [29] H. Holbrook, B. Cain Source-specific Multicast for IP, Internet Draft, November 2000. [30] S. Bhattachayya, C. Diot, L. Giuliano, R. Rockell, J. Meylor, D. Meyer, G. Shepherd, B. Haberman, An Overview of Source-Specific Multicast (SSM) deployment, Internet Draft, May 2001. [31] Rajvaidya, P. and Almeroth, K. and Claffy, K. A Scalable Architecture for Monitoring and Visualizing Multicast Statistics, Proc. IFIP/IEEE DSOM 2001, Ambler, A. and Calo, S. and Kar, G. (Eds)., LNCS 1960, pp.1-12, 2000. [32] R. Vida L. Costa, R. Zara, S. Fdida, S. Deering, B. Fenner, I. Kouvelas, B. Haberman Multicast Listener Discovery Version 2 (MLDv2) for IPv6, <draf-vida-mld-v2-01.txt>, july 2001. [33] I. Stoica, et al., "REUNITE: A recursive Unicast Approach to Multicast", Proc. Infocom 2000. [34] R. State and O. Festor Active Network based management for QoS assured multicast delivered media, Proc. IEEE Joint 4 th. International conference on ATM and High Speed Internet (ICATM2001). [35] http://developer.java.sun.com/developer/onlinetraining/rmi/rmi.html [36] http://www.savetz.com/mbone/toc.html [37] http://www.bora.net/techforum/thema2/mbone/m-debugging.htm [38]MMON specifications : http://www.hpl.hp.com/mmon/mmon-specs.html