Una Arquitectura de Gestión para Redes Activas

Transcripción

1 Una Arquitectura de Gestión para Redes Activas Proceedings of the Fourth Annual International Workshop on Active Middleware Services (AMS 02) - IEEE Traducido por Antonio Salavert A. Barone, P. Chirco Dipartimento di Ingegneria Informatica DINFO - Universit` a degli Studi di Palermo viale delle Scienze, Palermo, Italy G. Di Fatta, G. Lo Re CERE - CEntro di studio sulle Reti di Elaboratori C.N.R. - Consiglio Nazionale delle Ricerche viale delle Scienze, Palermo, Italy { difatta, lore Resumen En este documento presentamos una arquitectura para la gestión de redes y aplicaciones, que se basa en el paradigma de las Redes Activas y muestra las ventajas de la programación de la red. El estímulo para desarrollar esta arquitectura viene de una necesidad actual de gestionar un conjunto de nodos activos, donde a menudo se requiere volver a desplegar los activos de la red y modificar la conectividad de los nodos. En nuestra arquitectura, un remoto front-end de la entidad de gestión permite al operador diseñar las nuevas topologías de la red, verificar el estado de los nodos y configurarlos Además el marco propuesto permite explorar una red activa, monitorizar las aplicaciones activas, interrogar cada nodo e instalar traps programables. Con el fin de aprovecharnos de la tecnología de las Redes Activas, introducimos un SNMP activo como MIBs y agentes, que son dinámicos y programables. Los agentes programables de gestión hacen que el seguimiento de las aplicaciones distribuidas sea una tarea factible. Proponemos un marco general que puede interoperar en cualquier entorno activo de ejecución. En este marco ambos, el gestor y los front-end que monitorizan, se comunican con un nodo activo (el Active Network Access Point) a través del lenguaje XML. Un servicio de pasarela realiza la traducción de las solicitudes desde XML a un lenguaje activo del paquete e inyecta el código en la red. Demostramos la implementación de una pasarela activa de red para PLAN (Packet Language for Active Networks) en una red de prueba con 40 nodos activos. Finalmente, discutimos una aplicación de la arquitectura activa de gestión para detectar las causas de los fallos de la red mediante un seguimiento de los eventos de la red.

2 1. Introducción Tradicionalmente, las redes de telecomunicaciones tienen separados el nivel de gestión del nivel de comunicación; existen diferentes infraestructuras para la entrega de los datos del usuario y la entrega de la información y comandos intercambiados entre las entidades de gestión y los objetos gestionados. Este no es el caso de las redes de ordenadores y en particular con el Internet de hoy, donde los servicios de gestión y transporte comparten la infraestructura de comunicaciones. En la arquitectura de gestión de Internet hay tres componentes principales: una entidad de gestión, normalmente una aplicación centralizada que requiere intervención humana, los dispositivos gestionados, tales como equipos de red y su software, y el SNMP (Simple Network Management Protocol) [18]. El SNMP es el marco de gestión de red más ampliamente usado y desplegado y ha sido diseñado para ser independiente de los productos específicos de los fabricantes y de las redes. El SNMP es inherentemente un marco centralizado. Un programa agente embebido en un dispositivo de la red recoge las estadísticas de tráfico y guarda los valores de configuración en una MIB (Management Information Base). La entidad de gestión puede obtener la información del estado o modificar la configuración del dispositivo interrogando al agente. Los agentes de gestión tienen un papel activo limitado, p.e. solo pueden enviar un mensaje de trap asíncrono a la entidad de gestión cuando unos pocos determinados eventos ocurren, tales como bootstrap y fallos de enlace. En el marco SNMP los agentes de gestión no pueden gestionar los fallos localmente ni coordinar se con otros agentes de gestión. El alto número de nodos de una red en un dominio administrativo de Internet sugiere la adopción de una propuesta distribuida que suministre escalabilidad. Por otra parte una gestión customizable, p.e. el control correcto en el lugar oportuno, puede suministrar una eficiencia mejor. Se han propuesto varias propuestas distribuidas y programables de gestión de la red, que están basadas en paradigmas tales como Agentes Móviles y Redes Activas. Los autores en [16] proponen una arquitectura Smart Packets, que permite la ejecución remota de pequeñas porciones de código dentro de los objetos de la red para monitorizar y gestionar los clásicos objetos MIB. Sin embargo la arquitectura Smart Packets no permite la adición dinámica de nuevos objetos monitorizables en los nodos. Los autores en [10] tienen una meta análoga aunque adoptan la tecnología de agente móvil como nivel subyacente. Recientemente, los autores en [1] propusieron un marco general para la gestión de sistemas multimedia distribuidos. Esta marco adopta una organización jerárquica de agentes que se pueden iniciar dinámicamente por medio de filtros customizables que son diseminados apropiadamente entre todos los agentes de la red. Por esta razón, se requiere una actividad pesada de control para coordinar las acciones de gestión para la realización de las actividades requeridas. Aunque las Redes Activas son un camino prometedor para adoptar una propuesta de agente programable en la gestión de las redes de ordenadores, nos imaginamos un nuevo escenario y nos planteamos nuevos problemas. Mientras las actuales redes de datos son estáticas e imponen la definición a priori de las entidades que tienen que ser monitorizadas, las Redes Activas suponen una evolución dinámica del software de la red. Los nuevos servicios y aplicaciones de red se pueden desplegar fácilmente en la red y saltar el lento proceso de estandarización. En este caso, la gestión de la red tiene que tratar con un entorno altamente dinámico, sin la posibilidad de una definición estándar previa de los datos monitorizables. Por lo tanto, el protocolo SNMP actual no aparece como adecuado para los nuevos escenarios; los nuevos marcos de gestión se deben diseñar para tratar con los entornos dinámicos activos. En este documento proponemos una arquitectura de gestión de red activa, que adopta una estrategia de agentes programables distribuidos y una definición de MIB activa y dinámica, con el fin de superar la limitación del marco SNMP y permitir el desarrollo y

3 despliegue de nuevos servicios de gestión. El resto del documento se estructura como sigue. La sección 2 muestra los beneficios potenciales de las redes activas en la gestión de red. La sección 3 presenta el marco de gestión de redes activas. En la sección 4 se ilustra la implementación de la aplicación y el servicio y los servicios básicos de pasarela, y en la sección 5 se propone una aplicación de minería de eventos de red. Finalmente, se hacen algunos comentarios a modo de conclusión en la sección Beneficios Potenciales de las Redes Activas en la Gestión de la Red La programación introducida por las Redes Activas pueden representar el salto hacia una gestión generalizada de la red. El uso de servicios de red se extiende a la sociedad de hoy en día. La importancia de los servicios requiere que estén garantizados por medio de una continua monitorización para intervenciones inmediatas en caso de fallo. El concepto de Resiliencia en las Redes de Comunicaciones llega a ser una característica indispensable del diseño de la arquitectura de la red. La resiliencia se define normalmente como el conjunto de mecanismos que pueden hacer frente a los fallos de la red. En el campo de la gestión de red, esto se conoce como gestión proactiva. La gestión proactiva opera en el campo de los síntomas que predicen los eventos negativos con el fin de evitarlos. En este escenario las Redes Activas pueden ser un instrumento adecuado para la implementación de un sistema completo de gestión. Los beneficios actuales que las aplicaciones de gestión pueden obtener de la adopción de las Redes Activas, caen en las categorías siguientes: disponibilidad de información mantenida por los nodos intermedios; capacidad de procesamiento de datos a lo largo del camino; adopción de estrategias distribuidas y autónomas en la red. Las características anteriores contestan completamente los requerimientos de gestión de red. Los agentes móviles pueden ser encapsulados y transportados en el código activo de las cápsulas de la aplicación. Pueden recuperar y extraer trozos de información mantenidas en los nodos intermedios de una forma más efectiva que a través de solicitudes remotas de la propia aplicación. Por ejemplo, un agente puede hacer uso de un código activo para buscar objetos MIB de un nodo intermedio y seleccionar algunas entradas de acuerdo con un criterio dado. Puede devolver la información extraída a la aplicación o puede usar la información para tomar las decisiones oportunas autónomamente de la aplicación. Se pueden encontrar más ejemplos en otras cuestiones de gestión de red, tales como el control de la congestión, la gestión de errores, o la monitorización de tráfico. Un ejemplo significativo es la customización de la función de encaminamiemto. Un agente móvil se puede dedicar a la evaluación del camino para el flujo de datos de la aplicación, de acuerdo con la especificación QoS del usuario. Cada aplicación puede establecer su propia política de control y explotar un servicio común (la función por defecto del encaminamiento es por salto). Las aplicaciones de las redes activas se pueden implementar fácilmente con estrategias distribuidas extendiéndolas a los agentes móviles de gestión de la red. La introducción de la programación del nodo de la red hace del sistema de la red una única base de conocimiento, que también es capaz de producir nueva información. Esto sucede, por ejemplo, cuando se generan nuevas acciones deducidas de la resolución de los datos previamente almacenados con acontecimientos de determinados eventos, permitiendo así la inferencia de nuevos eventos y el desencadenamiento de medidas codificadas.

4 3. Marco de Gestión de Redes Activas En esta sección presentamos una arquitectura para la gestión y monitorización de Redes Activas. Las Redes Activas introducen programación en la red; los nuevos componentes de software se pueden inyectar dinámicamente en la red para ser ejecutados en los nodos intermedios. La gestión de la red llega a ser aún más importante que en las redes tradicionales y se pueden llevar a cabo tareas más complejas. El marco y las herramientas tradicionales de gestión de red se dirigen a la gestión de los dispositivos de la red y su software, lo que no significa cambiar frecuentemente. En el marco tradicional SNMP sería más difícil, si no imposible, rastrear, corregir, y monitorizar las aplicaciones distribuidas dinámicamente desplegadas en la red. En la arquitectura propuesta introducimos características de programación en la MIB (Management Information Base) y en los agentes locales para hacer que una aplicación de gestión sea distribuida, cooperativa, y adaptativa. Además señalamos que la dirección del marco de Gestión de Redes Activas debe tomar en cuenta la gestión de las aplicaciones activas. La gestión de aplicaciones activas incluye el despliegue, la integración, y la coordinación de los componentes de software para monitorizar, chequear, interrogar, configurar, analizar, evaluar, y controlar las aplicaciones de red distribuidas y sus recursos de la red. En el marco (figura 1) la Entidad de Gestión (ME - Managing Entity) opera por medio de una interfaz gráfica de usuario. Envía solicitudes y recibe respuestas en XML (Extensible Markup Language) hacia y desde un AN Access Point. Un AN Access Point es un nodo activo con un servicio de Gateway. Un servicio de Gateway tiene dos tareas: la traducción de las solicitudes XML en un determinado lenguaje adoptado por el EE (Execution Environment) y la inyección en la red de las apropiadas cápsulas activas que realizan las solicitudes del ME. De esta forma el Gateway actúa como una interface para una determinada red activa y es específica para el lenguaje soportado por su EE. Varios nodos de la red activa se pueden configurar para suministrar los servicios de Gateway. Como se ilustra en la figura 1, un servicio de gestión residente, el ALA (Active Local Agent), se instala en cada nodo activo. ME y ALA son los extremos de la comunicación

5 de la gestión. A saber el ME o puede preguntar a los Active Local Agents (con sondeo) o desplegar subtareas en ellos (traps programables). Asíncronamente los agentes locales realizan subtareas en términos de Acciones que se ejecutan con las ocurrencias locales de Eventos, como se explica a continuación. La arquitectura se puede compartir por diferentes implementaciones de AN y puede suministrar un marco común de gestión para diferentes EEs. Tenemos que adoptar XML para definir un conjunto de solicitudes/respuestas para las tareas operacionales básicas, que son comunes a cualquier entorno de Red Activa. Los servicios básicos de Gateway que normalmente tenemos que implementar se presentan en 4.1. Sin embargo el conjunto de servicios de Gateway se pueden ampliar gradualmente. Una vez se desarrolla y chequea un nuevo servicio, se puede suministrar para el uso público. Cada servicio básico requiere un fragmento de código específico para EE almacenado en el Gateway. De esta forma los nodos del Gateway suministran acceso transparente a las diferentes Redes Activas. Por ejemplo el ME puede usar los servicios del Gateway para descubrir la topología de la red, explorar los nodos de la red, encontrar que aplicaciones activas están corriendo y monitorizar sus actividades. Además el ME puede incluir código específico de EE en solicitudes XML para implementar los servicios de gestión customizados. Se suministrar una marca determinada para convertir el código de usuario en solicitudes XML. El código de usuario causa problemas de seguridad que se pueden gestionar por medio de autenticación y políticas de autorización y la limitación en el lenguaje de programación. Estamos particularmente interesados en la gestión de una red de pruebas de Red Activa donde también se requiera tareas de gestión no corrientes, definiendo así la topología de la red a ser desplegada. Para este fin el GUI suministra un editor de topología y el Gateway puede gestionar la configuración y las fases de arranque de los EEs en los nodos activos. 3.1 MiB Activa y Agente Local Activo En el diseño de nuestra arquitectura nos alejamos del marco tradicional SNMP e introducimos las ventajas de la programación del paradigma de las Redes Activas. Redefinimos el papel del agente de gestión y adoptamos un modelo diferente para la MIB. En el marco tradicional SNMP, un dispositivo gestionado es un equipo de la red que, en general, puede contener varios objetos monitorizables, ya sean de hardware o software (por ejemplo tarjetas de interface de red y protocolos de encaminamiento). En este protocolo la Entidad de Gestión puede solicitar las operaciones básicas locales a los agentes SNMP de la MIB, p.e. Set y Get el valor de los objetos. Distinto del esquema SNMP, en nuestro modelo el ME puede programar el comportamiento local de los agentes para cumplimentar tareas independientes. Consecuentemente se pueden llegar a desplegar estrategias distribuidas. Mientras que los agentes locales SNMP solo tienen capacidades preconfiguradas, el Agente Local Activo es programable. También se añade un grado de programación a los objetos MIB con la adopción del paradigma de la programación orientada a objetos. En nuestro marco, los objetos gestionados son aplicaciones activas, que son aplicaciones distribuidas cuyos componentes de software corren tanto en los nodos finales como en los nodos intermedios de la red. Una aplicación puede suscribir el servicio gestión/monitorización en un nodo registrando una ID única a un agente local. Una vez registrado, puede almacenar la información en la MIB local Activa (AMIB). Un objeto AMIB está relacionado con un componente de una aplicación gestionada en el nodo activo. La estructura del objeto AMIB permite a las aplicaciones almacenar datos y, eventualmente, un código relacionado. Cada objeto no es solo una única variable que almacena un valor, sino que también puede contener algún código representando un conjunto de condiciones llamadas filtros. En el ALA, implementamos un modelo Eventos-Acciones, como se muestra en la figura 2. Los Filtros

6 AMIB son pares <Prueba,Evento>, donde la prueba es una expresión Booleana construida sobre predicados básicos por medio de operadores lógicos (AND y OR). Una verificación del filtro indica que ha ocurrido este Evento. La prueba del filtro se ejecuta con los datos cuando ocurre una llamada Set que es una primittiva de datos, p.e. cada vez que cambian los datos. Si la prueba es satisfactoria, el evento asíncrono asociado con el filtro se activa y es sometido al Programador de Acciones. Se debería observar que, mientras los eventos de la primitiva Set_data son independientes de la aplicación, los eventos producidos por los filtros siguen la semántica de la aplicación. Además los eventos son generados por un proceso de sincronización conectado al reloj del sistema. El reloj del sistema está sincronizado con el tiempo global de una función de tiempo de referencia por medio del protocolo NTP (Network Time Protocol). El NTP suministra normalmente precisiones del orden de los milisegundos en las LANs y hasta unas pocas decenas de milisegundos en las WANs [13]. El agente local gestiona una lista de pares <Evento,Acción>, que son acciones programadas para los eventos síncronos y asíncronos. Las aplicaciones pueden activar acciones a ser ejecutadas por el ALA en correspondencia a determinados eventos. Las cápsulas activas de entrada pueden acceder los datos y el código a la AMIB y la lista de Acciones a través de servicios suministrados por los módulos Interface del Agent y Cumplimiento de Políticas (Set/Get de datos, filtros, acciones). En general, las acciones son en forma de cápsulas activas, que son activadas para realizar la tarea requerida. Por ejemplo, como consecuencia de un evento de overflow de una cola de espera, se puede enviar simplemente un trap de información al ME a través de una cápsula que contenga un mensaje de aviso, o una acción proactiva que se puede tomar por medio de un código más complejo en la cápsula. En general, los filtros AMIB se pueden inyectar o por la propia aplicación (el propietario de los datos) o por una aplicación diferente, p.e. la entidad de gestión. Con el fin de limitar los efectos de código malicioso o que funcione mal, los filtros no pueden acceder a las primitivas de la red ni hacer llamadas recursivas y las Acciones no pueden desencadenar Eventos locales. La restricción en los filtros y las acciones se puede sintonizar con una política de seguridad apropiada basada en autenticación y

7 autorización. En una infraestructura de una red pública una política de seguridad en la gestión de la AMIB, los datos, filtros y acciones ha de ser obligatoria por el ALA. Sin embargo esto está fuera del objetivo de este documento. Ahora el marco de gestión se considera activo porque, primero, las MIBs contienen datos y código, y segundo, cada agente local de gestión (ALA) juega un papel activo en la gestión de la red realizando independientemente tareas programadas. 4. Implementación de las Aplicaciones y Servicios El marco descrito en este documento se origina como consecuencia de una necesidad práctica de gestión de una red activa. Hemos realizado una red experimental de pruebas con 40 nodos activos con el fin de investigar el nuevo paradigma de las redes activas. Normalmente el banco de pruebas se usa para el desarrollo y pruebas de los nuevos protocolos y aplicaciones: [3], [8], [6], [7]. El laboratorio experimental se constituyó con una red completamente conectada de nodos activos, que nos permiten realizar determinadas topologías de acuerdo con las necesidades de la investigación. Cada nodo está implementado por una estación de trabajo Linux equipada con cuatro tarjetas de red Ethernet a 100 Mbps con el fin de emular un enrutador activo de cuatro puertos. Los nodos activos están equipados con los paquetes de software principal para la red activa como PLAN [12], ANTS [22], ASP [14]. El marco de gestión descrito en la sección anterior permite la monitorización y gestión de los servicios y aplicaciones de la red. Además el marco de gestión asume un papel relevante en la fase de desarrollo de las aplicaciones de la red. Una aplicación de la red es completamente responsable de la selección de sus propios datos internos que pueden ser observados por otras aplicaciones (p.e. el ME). La aplicación puede decidir que datos del MIB activo se pueden monitorizar. La monitorización variable es muy útil durante la actividad de prueba y corrección. Además las MIBs activas permiten la realización de un sistema de comunicación entre aplicaciones de red cuando los objetos AMIB se usan como variables de memoria compartida. La comunicación inter-aplicaciones hace posible nuevos servicios de red: las aplicaciones pueden aprovecharse de los datos recogidos por otras aplicaciones. Se han desarrollado y probado varias funcionalidades simples de un Gateway de red activa como servicios activos en el entorno de ejecución PLAN (ver 4.1). Por ejemplo, desarrollamos un servicio, llamado Delivery MST, con el fin de optimizar la visita de todos los nodos de la red. Dada una tarea, el servicio entrega y ejecuta la tarea en cada nodo. El servicio construye un spanning tree mínimo temporal con los resultados que progresivamente surgirán y finalmente entregarán a la fuente. El servicio es óptimo con el consumo de ancho de banda y evita mensajes de implosión en la fuente. Los patrones de navegación son estrategias para moverse de un nodo a otro de la red como parte de la ejecución del programa. Los patrones simples de navegación se describen en [9]; el servicio Delivery MST se puede considerar un patrón avanzado de navegación. Además los eventos síncronos permiten una implementación fácil y simple de un servicio snapshot. Por medio de este servicio es posible capturar todos los valores asumidos por el AMIB investigado en un instante determinado en todos los nodos de la red. Otros servicios que implementamos incluyen descubrimiento de la topología, monitorización de los caminos de los paquetes activos, monitorización de las tablas de encaminamiento, etc.. Las aplicaciones externas pueden usar los Servicios básicos de Gateway para obtener información de los servicios activos disponibles en un nodo y encontrar las situaciones de fallo.

8 4.1 Servicios Básicos de Gateway Una red activa puede tener muchos Puntos de Acceso (AP) que suministren servicios de Gateway. Desde cualquier Punto de Acceso (AP) es posible interrogar a los nodos activos. Los servicios de Gateway son relativos a la red o a los niveles de la aplicación, y caen dentro de dos categorías: servicios públicos y servicios administrativos. Los servicios públicos no modifican la configuración de la red activa y permiten ejecuciones múltiples y concurrentes. Por el contrario, con el fin de evitar conflictos, se adopta una técnica de exclusión mutua para garantizar que solo un administrador ha sido autenticado y está ejecutando operaciones administrativas. A continuación presentamos brevemente los servicios que hemos implementado en nuestro banco de pruebas dentro del PLAN EE. Nivel de Red Activa. Servicios Públicos Get Topology Este servicio obtiene la topología de la red activa actual y la información del estado de los nodos activos. Ping Este servicio usa el comando ping de UNIX para comprobar si un nodo es accesible a nivel de red. Active Ping Esta versión activa del comando ping usa mensajes activos para verificar si un nodo es accesible a nivel de red activa, p.e. en el nivel de Entorno de Ejecución. Get Routing Table Este servicio suministra la tabla de encaminamiento de un nodo activo. Nivel de Red Activa. Servicios Administrativos Set Topology En el banco de pruebas experimental este servicio define la topología de la red activa. Genera y despliega la configuración requerida para cada nodo activo. Bootstrap AN Este servicio arranca los procesos EE en todos los nodos activos. El servicio está disponible solo si la configuración de la topología ha sido desplegada por el servicio Set Topology. Shutdown AN Este servicio para los procesos EE de todos los nodos activos. Set Static Route Este servicio establece una ruta estática entre un origen y un destino Delivery Path Este servicio genera una cápsula activa, que visita el nodo activo de un determinado camino origen-destino para ejecutar una determinada tarea. La tarea es un fragmento de código, que es suministrado por el usuario en el lenguaje soportado por el EE. Delivery Path&Return Como el Delivery Path, pero en este caso el camino es atravesado en las dos direcciones, ida y vuelta. Cada nodo es visitado dos veces. A la vuelta los resultados del camino se irán recogiendo conjuntamente y entregados finalmente en la fuente de la solicitud. Delivery MST Este servicio genera una cápsula activa, que visita óptimamente la red activa para ejecutar una determinada tarea en cada nodo activo. El servicio construye un spanning

9 tree mínimo temporal con los resultados del camino que se irán recogiendo conjuntamente y entregados finalmente en la fuente de la solicitud. Delivery Tree Como el Delivery MST, pero en este caso los nodos a ser visitados son un subconjunto de los nodos de la red. Nivel de Aplicación Activa. Servicios Públicos Get Applications List Este servicio obtiene la lista de aplicaciones activas que han almacenado datos en la AMIB de un determinado nodo activo. Get Data List Este servicio obtiene la lista de las IDs de los objetos AMIB de una determinada aplicación en un nodo activo. Get Value Este servicio obtiene el valor actual de unos determinados datos AMIB de una aplicación determinada en un nodo activo. Get Filters List Este servicio obtiene los filtros activos asociados a unos determinados datos AMIB de una aplicación determinada en un nodo activo. Get Events List Este servicio obtiene los Eventos de una aplicación determinada en un nodo activo. Los Eventos de Aplicación están definidos en los filtros y acciones. Get Actions List Este servicio obtiene la lista de Acciones de una determinada aplicación en un nodo activo. Get Action Code Este servicio obtiene el fragmento de código de la Acción de una determinada aplicación en un nodo activo. Nivel de Aplicación Activa. Servicios Administrativos Set Value Este servicio establece el valor de un determinado objeto AMIB de una aplicación determinada en un nodo activo. Set Filters Este servicio modifica los filtros activos asociados a unos determinados datos AMIB de una aplicación determinada en un nodo activo. El establecimiento de una lista vacía de filtros se usa con el fin de eliminar filtros. Set/Remove Action Este servicio modifica las acciones activas de una determinada aplicación en un nodo activo. Se debería observar que una aplicación activa siempre puede obtener y eliminar sus propios datos, filtros y acciones a través de servicios ALA de un nodo activo. Este proceso no engloba los servicios de Gateway anteriores, que son suministrados a las entidades de gestión/monitorización. Finalmente los prototipos de mensaje XML de la solicitud y respuesta del servicio Get Topology se dan como ejemplo.

10 < request command = get_topology > </request > < response command = get_topology > <status ></status> < net nodenum = maxdegree = > <nodename= degree = > < coord x = y = >< /coord > <adjacname= cost = >< /adiac > <addr></addr> <port ></port> </node> </net > < /response > En la siguiente sección discutimos una aplicación de una arquitectura activa de gestión para detectar las causas de los fallos de la red rastreando a la vez en los eventos de la red. 5. Minería de los Eventos de la Red Una aplicación, que se puede aprovechar de la arquitectura propuesta en este documento, está relacionada con la gestión del conocimiento de los eventos de la red. Para distintas metas de la gestión, es necesario adquirir a menudo información de los ficheros log de muchos dispositivos de red. Sin embargo puede resultar extremadamente caro almacenar todos los eventos que ocurren en todos los dispositivos de la red en un período largo de tiempo Sería más eficiente poder distinguir que eventos deben ser almacenados y cuales no añaden más conocimiento a la historia de la red. La Minería de los Eventos de la Red (NEM-Network Events Mining) trata con grandes archivos de eventos obtenidos de los sistemas de la red, y extrae la información útil de estos datos. Los objetivos de los sistemas NEM son: diagnosticar las causas principales de los fallos de la red y las degradaciones del rendimiento mediante el establecimiento de relaciones entre los eventos de la red; filtrar el flujo de eventos (alarmas) mediante la correlación de varios eventos en un solo evento conceptual. Los sistemas NEM útiles suministrarían: exactitud: las causas principales se pueden deducir con la NEM lo que supondría la detección de los eventos con una alta probabilidad, p.e. las causas principales que han ocurrido realmente en la red; óptimo: la NEM debería inferir con las mínimas causas principales que pueden explicar todos los eventos detectados. Una Entidad de Gestión con funcionalidades NEM puede adoptar un modelo dinámico de una red y un motor lógico para generar una base de conocimiento distribuida, donde solo se almacena la información esencial para describir la historia del sistema. La palabra historia se refiere aquí a un período limitado en el pasado, del cual el inicio se avanza continuamente con el paso del tiempo. El conocimiento de los eventos de la red constituyen la información necesaria para contestar las preguntas sobre las causas de los fallos de la red. La gestión de fallos se basa en la definición de las condiciones

11 normales de operación, y en la detección de las anormalidades. En general, las alarmas se generan en la red cuando se detectan anormalidades. En los sistemas de detección de fallos basados en alarmas, a menudo un solo fallo causará un gran número de alarmas. Además pueden coexistir varios fallos causando una cascada de alarmas. La NEM puede correlacionar las alarmas determinando sus causas principales con el fin de manejarlas eficientemente. Normalmente estamos desarrollando una entidad de gestión ME, que puede localizar las causas reales de los fallos de la red. El motor ME se basa en el cálculo de la situación y específicamente en el lenguaje Golog [15]. El Cálculo de la Situación es un dialecto de la lógica de primer orden y permite el modelado de sistemas dinámicos. Este cálculo captura el dinamismo de un sistema, ya que permite la definición de acciones que mueven el sistema de un determinado estado a otro. Todos los cambios en el mundo son los resultados de las llamadas acciones. Una historia posible del mundo es simplemente una secuencia de acciones, y está representada por un término de primer orden, llamado una situación. Mientras que el Cálculo de la Situación permite la representación de acciones simples, el Golog es un nuevo lenguaje lógico de programación, que permite el modelado de comportamientos complejos. Particular atención se debe pagar a los aspectos ontológicos de la base de conocimiento. Una representación efectiva estructurada de los eventos y acciones de la red puede mejorar mucho el proceso lógico deductivo. Esta Entidad de Gestión trata de resolver la ocurrencia de un determinado evento dentro de su propia base de conocimiento y, cuando es posible, deduce una conclusión. Si no se deduce ninguna conclusión de la actual base de conocimiento, el ME puede desencadenar más investigaciones con el objetivo de adquirir nueva información, hasta que se resuelve la incertidumbre. La nueva información se inserta en la base de conocimiento solo si no es deducible de forma efectiva. En términos del primer orden lógico, esto significa que no es una consecuencia lógica de los hechos en que se basa. De esta forma la base de conocimiento se guarda en su forma mínima. Además el cálculo de la situación es adecuado para la codificación de comportamientos proactivos del ME. En un lenguaje lógico de programación, resulta fácil implementar reglas para reconocer situaciones que son el prólogo de problemas incipientes, p.e. fallos de la red o ataques de piratas, y codificar las oportunas contramedidas. Ambas, las capacidades de obtener nueva información y de implementar políticas de recuperación y seguridad, están relacionadas con la programación introducida por las redes activas. La programación de los nodos activos permite la customización de determinadas tareas para investigar aspectos desconocidos de la historia de la red, realizar acciones proactivas para evitar fallos, y resistir a los ataques. Por simplicidad definimos un evento como una ocurrencia instantánea en un momento dado. Se asume que el tiempo será discretizado. Cada evento esta asociado con el objeto AMIB donde ocurre. Los objetos AMIB se pueden ver como conjuntos de atributos, y los eventos como un cambio en el estado del atributo. Los eventos se pueden clasificar como primitivos o compuestos. Los eventos primitivos se generan cuando cambia alguno de los atributos del objeto, mientras que los eventos compuestos no son directamente observables. Por ejemplo, un fallo del enrutador se puede inferir de un fallo persistente de una conexión. Consideramos dos formas de correlaciones de eventos como en [11]: las correlaciones causales y las temporales. La correlación causal expresa la relación de causalidad, p.e. una dependencia causa-efecto. Por ejemplo, esta clase de correlación se puede adoptar para establecer las causas principales de los fallos. La correlación causal se puede expresar fácilmente como una teoría lógica de primer orden en que son asiomatizadas las propiedades simples como la reflexividad, transitividad y la unión. Además podemos establecer aún correlaciones más fuertes entre eventos basados en sus ocurrencias temporales. Algunos ejemplos son relaciones tales como: e1 seguido por e2, primero e1 después el reciente e2. En [11] se muestra que la correlación temporal es más potente que la causal. La correlación causal

12 de eventos no permite cubrir todas las posibles relaciones de eventos, y la correlación temporal es necesaria para expresar la dependencia de los eventos persistentes. Los esfuerzos actuales están dirigidos a dibujar correlaciones de eventos con el fin de inferir los eventos compuestos del conocimiento de los eventos previos (ya sean primitivos o compuestos) para diferentes hitos de gestión. 6. Resumen y Conclusiones Este documento presenta un marco de gestión de red activa que explota la programación de la red en los posibles agentes basado en estrategias distribuidas. La arquitectura propuesta es capaz de gestionar tanto los Entornos de Ejecución de la red activa como de las Aplicaciones Activas que corren en ellos. Su principal característica consiste e la extensión de los objetos de MIB clásicos en unas entidades más potentes donde el código customizable del usuario está asociado a los datos de la red. El marco Filtros Eventos - Acciones mejora la eficiencia de gestión y permite los nuevos servicios de gestión. Finalmente se propone una estrategia de minería de eventos de red para extraer solamente la información útil de los datos de la red para los distintos objetivos de gestión. Referencias [1] Al Shaer E., Active Management Framework for Distributed Multimedia Systems, Journal of Networks and Systems Management, vol. 8 n. 1, 2000, pp [2] Bhattacharjee, S., Calvert, K.L., Zegura, E.W.: Active Networking and End-to-End Arguments, IEEE Network Special Issue on Active and Controllable Networks, vol. 12, n. 3, May-June 1998 [3] A. Chella, G. Di Fatta, G. Favar` o, M.D. Guarino, G.Lo Re, A Reconfigurable Neural Environment on Active Networks, Proc. of IEEE IJCNN2000, Como, Italy, July 2000 [4] Chen, T. M., Evolution to the Programmable Internet, IEEE Communications Magazine, vol.38, n. 3, March [5] L. Delgrossi, G. Di Fatta, D. Ferrari, G. Lo Re, Interference and Communications among Active Network Applications, Lecture Notes in Computer Science vol. 1653, Springer-Verlag, pagg , Proc. of IWAN 99, Berlin, Germany, 30 June - 2 July [6] Di Fatta G., Gaglio S., Lo Re G., Ortolani M., Adaptive Routing in Active Networks, IEEE Openarch 2000, Tel Aviv Israel March [7] G. Di Fatta, G. Lo Re, Active Networks: an Evolution of the Internet, Proc. of AICA th Annual Conference, Cernobbio, Italy, Sept [8] G. Di Fatta, S. Gaglio, G. Lo Re, M. Ortolani, Artificial Ants for Active Routing, IAS6, the 6th Inter-national Conference on Intelligent Autonomous Systems. Venice,July [9] Kawamura R., Stadler R., Active Distributed Management for IP Networks, IEEE Communicatiions Magazine, vol. 38, N 4. April 2000, pp [10] Goldszmidt G., Yemini Y, Delegated Agents for Network Management, IEEE Communicatiions Magazine, vol. 36, N. 3 March 1998, pp [11] Hasan, M., Sugla, B., Viswanathan, R.: A Conceptual Framework for Network Management Event Correlation and Filtering Systems. Proc. of Sixth IFIP/IEEE International Symposyum on Integrated Management, May 1999 [12] Hick, M., et al, PLAN: A Packet Language for Active Networks, Proc. of 3rd ACMSIGPLAN International Conference on Functional Programming, pages ACM, September [13] Mills D. L., On the accuracy of Clocks Synchronized by the Network Time Protocol in the Internet System, ACM Computer Communication Review, vol. 20, no. 1, pp ,

13 Jan [14] G. Phillips, B. Braden, J. Kann, and B. Lindell. Writing an Active Application for the ASP Execution Environment (Release 1.3) [15] Reiter Raymond, Knowledge in action: Logical Foundations for specifying and implementing Dynamical Systems The MIT Press Cambridge Massachusetts 2001 [16] Schwartz B. Y., et al, Smart Packets: applying Active Networks to Network Management,ACMTransaction on computer Systems, Vol. 18, N. 1, February 2000, pp [17] Smith, J. M., Calvert, K.L., Murphy, S. L., Orman, H. K., Peterson, L.L.: Activating Networks: A Progress Report. IEEE Computer, Vol. 32 N. 4, April 1999, [18] Stallings W., SNMP and SNMPv2: The Infrastructure for Network Management, IEEE Communicatiions Magazine, vol. 36, N. 3 March 1998, pp [19] Tennenhouse, D. L., Smith, J.M., Sincoskie, W.D., Wetherall D.J., Minde, G.J.: A Survey of Active Network Research, IEEE Communications Magazine, Vol. 35, No. 1, January 1997, 8 [20] Tennenhouse, D. L., Wetherall, D.J.: Towar ds an Active Network Architecture, Computer Communication Review, Vol. 26, No. 2, April 1996 [21] Wetherall, D.J., Legedza, U., Guttag, J.: Introducing New Internet Services: Why and How, IEEE Network Magazine Special Issue on Active and Programmable Networks, vol. 12, n.3, May-June 1998 [22] Wetherall, D.J., Guttag, J., Tennenhouse, D.L.: ANTS: A Toolkit for Building and Dynamically Deploying Network Protocols, IEEE OPENARCH 98, San Francisco, CA, April 1998