Utilisation de DCE au sein du laboratoire de Télécommunications

La demande de services avancés tels que ceux multimédia est croissante. Ces services induisent des exigences plus fortes que celles satisfaites par les infrastructures de réseaux actuelles telles que le réseau intelligent (RI). En effet, ce dernier dans son état de développement présent se confine au contrôle d'appels téléphoniques, de plus, sans véritablement fournir de cadre de gestion de la communication. Or pour la mise en oeuvre de services multimédia, accès plus flexible, transparence par rapport aux réseaux sous-jacents, et gestion mieux adaptée en particulier en terme de connectivité, tarification et sécurité sont autant d'exigences à satisfaire.

Les futures architectures de réseaux d'information de télécommunication sur lesquelles seront déployés les services de télécommunication avancés tels que les réseaux privés virtuels large bande ou les services multimédia se doivent d'intégrer les concepts du réseau intelligent, du réseau de gestion de télécommunication (RGT) en s'appuyant sur le traitement réparti ouvert (ODP ­ Open Distributed Processing) et l'approche orientée objet. En effet, un service de télécommunication peut être vu comme une application distribuée s'exécutant sur les différents noeuds d'un réseau de télécommunication. Afin de faciliter la création, le déploiement et l'exploitation de ces services, l'architecture de réseaux cible doit correspondre à une plate-forme distribuée enrichie de serveurs spécifiques au domaine des télécommunications. Le premier serveur à réaliser et à mettre à la disposition des services de télécommunication est le serveur de gestion des connexions. Son rôle est l'établissement, le contrôle et la libération de connexions semi-permanentes ou permanentes par la gestion et non la signalisation.

Dans ce contexte, nous avons mis en oeuvre l'architecture logicielle OAMS (Open Service Architecture for Multimedia Services Over ATM [Asynchronous Transfer Mode]) pour permettre l'introduction de services de télécommunication avancés et services de gestion. Ces derniers sont utilisés afin de gérer les réseaux sur lesquels s'exécutent les services de télécommunication. OAMS raffine la plate-forme distribuée DCE (Distributed Computing Environment) avec un serveur de gestion des connexions (figure 1). Bien que conceptuellement ce serveur permette de mettre en oeuvre des connexions sur tout type de réseau de télécommunication, il a été implanté pour la technologie de réseau ATM.

Figure 1: L'architecture OAMS

A l'implantation, le serveur de gestion des connexions consiste en un ensemble d'objets tous déployés sur DCE. Conceptuellement, l'architecture de gestion des connexions consiste en quatre niveaux ou couches, à savoir: couches gestion des éléments du réseau (EML ­ Element Management Layer), gestion du réseau de communication (CNML ­ Communication Network Management Layer), gestion du réseau d'usager (UNML ­ User Network Management Layer) et gestion du service (SML ­ Service Management Layer). Dans chaque couche sont présents des objets informationnels et fonctionnels. Les objets informationnels modélisent par des données les ressources à gérer. Les objets fonctionnels modélisent la fonctionnalité, ici la gestion de la connexion (établissement, libération, contrôle). Ces derniers interagissent toujours avec les objets informationnels qui leur fournissent les moyens de mettre en oeuvre la connectivité à travers des entités connexion. C'est au niveau le plus bas que les connexions sont effectivement établies dans les commutateurs (figure 2).

Figure 2: Architecture de gestion des connexions dans OAMS

Dans la couche gestion des éléments du réseau sont présents les objets ECM (Element Connection Manager) et EIM (Element Information Manager). L'objet EIM modélise un commutateur et la connectivité en son sein. L'objet ECM gère cette connectivité. Il existe une instance de ECM et EIM par commutateur.

Dans la couche gestion du réseau de communication, on trouve les objets CNIM (Communication Network Information Manager) et CNCM (Communication Network Connection Manager). CNIM représente par les données un réseau de télécommunication (ensemble de commutateurs et liens entre ces commutateurs) alors que l'objet CNCM gère la connectivité de bout en bout au sein d'un réseau de communication. La vision de chaque commutateur est fournie par la couche EML. Une instance de CNCM et une instance de CNIM sont créées pour chaque réseau de communication.

Dans la couche gestion du réseau des usagers, sont déployés les objets UNCM (User Network Connection Manager) et UNIM (User Network Information Manager). Un réseau d'usager est en fait le réseau d'entreprise qui est constitué de réseaux privés distants interconnectés par des réseaux de télécommunication. UNIM modélise le réseau d'usager avec les points d'accès usager au réseau. UNCM établit, maintient et libère des connexion entre deux points d'accès usager.

Enfin la couche gestion de service encapsule les objets SSM (Service Session Manager) et SIM (Service Information Manager). SSM gère les sessions de service (création d'une session, ajout/retrait d'un utilisateur à une session, libération de la session) alors que SIM modèle l'ensemble des sessions de service.

Avec OSF DCE version 1.0, chaque processus généré occupe 2,5 M octets sur le disque. L'efficacité et les contraintes d'espace mémoire n'ont pas été des problèmes puisque peu de processus ont été déployés. A l'exécution, un seul commutateur ATM Fore ASX 200 a été considéré; n'étaient donc présents qu'une instance des processus ECM, EIM, CNIM, CNCM, UNCM, UNIM, SSM et SIM. Nous devons aussi considérer le fait que la version DCE 1.1 qui est déjà commercialisée et qui améliore significativement les performances de DCE 1.0 devrait aider à résoudre les problèmes de mémoire et d'efficacité.

Pour valider l'architecture OAMS, a été développé une application de vidéoconférence (figure 3). Chaque utilisateur possède un processus pour l'émission et la réception de flux audio/vidéo et un processus pour réaliser le contrôle de l'application, c'est à dire l'établissement/libération d'une session de vidéoconférence, l'ajout/retrait d'un utilisateur, le changement des paramètres de qualité de service, etc. Les requêtes de contrôle sont transportées à travers DCE alors que le transfert des flux audio/vidéo est directement mis en oeuvre à travers l'API (Application Programming Interface) ATM. Le serveur de gestion des connexions est l'entité responsable de la réalisation effective des requêtes de contrôle utilisateur; il a donc la responsabilité d'établir la connectivité physique entre les utilisateurs impliqués dans une session.

Figure 3: Déploiement d'une application de vidéo-conférence