CONSULTORÍA ESTRATÉGICA EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIONES
La gestión de red es el conjunto de actividades dedicadas al control y vigilancia de la infraestructura de telecomunicaciones de una empresa u operadora. Las áreas fundamentales en las que actúa son la gestión de fallos, la gestión de la configuración, la gestión de la seguridad, la gestión de la ejecución y la gestión de la contabilidad.
Durante los años del monopolio, con la gestión de red se buscaba, además de encontrar y solucionar problemas, automatizar de forma remota y centralizada, aquellas tareas que consumían mucho tiempo de los operadores o bien su desplazamiento en local, como efectuar cambios en la configuración de los equipos o gestionar su rendimiento. La liberalización de los antiguos monopolios de telecomunicaciones, a finales de los años 1990, supuso serios cambios en la gestión de red, haciéndose necesario, entre otras cuestiones: controlar un número creciente de equipos y tecnologías de diferentes suministradores, e introducir nuevos servicios de forma gradual. Por otro lado, cada vez se valora más que los sistemas permitan conocer no sólo los fallos que se pueden estar produciendo en la red en un momento determinado, sino poder anticiparse a los mismos, estar preparado y saber cómo reaccionar en caso de que se produzcan. Es muy importante además que el sistema de gestión proporcione la información adecuada, pues es tan mala la falta de información como el exceso.
La heterogeneidad de los equipos involucrados dentro de una misma red, así como el lento proceso de estandarización, ha supuesto que cada suministrador (Alcatel, Cisco, Ericsson, Lucent, Nortel, etc.) haya ido desarrollando herramientas software de gestión distintas con un formato de las bases de datos incompatible en muchos aspectos. Es más, cada tecnología (ADSL, HFC, SDH, DWDM, ATM, LMDS, etc.) de la red a supervisar, utiliza aplicaciones de gestión diferentes, desarrolladas en diferentes lenguajes de programación y soportadas sobre diferentes sistemas operativos. El crecimiento de las redes ha supuesto también que las bases de datos, que antes estaban centralizadas en un único servidor de gestión, sean distribuidas a lo largo de varios servidores. De hecho, muchas de esas bases de datos son redundantes, con el fin de aumentar la robustez del sistema ante fallos habituales (fallos hardware, fallos de sistemas operativos, ataques de virus, etc.). El aumento de la competencia ha derivado en un vertiginoso ritmo de desarrollo de nuevos servicios, cada vez más avanzados y personalizados, por lo cual es imprescindible que el sistema de gestión permita que estos servicios sean implementados de forma gradual.
El término TMN (Telecommunications Management Network) fue introducido por la ITU-T (International Telecommunications Union – Telecommunication sector) en 1988, para conseguir el desarrollo de entornos de gestión distribuidos y heterogéneos. TMN, definido en el conjunto de recomendaciones M.3000, proporciona una arquitectura en capas para todas las funciones de las aplicaciones de gestión de red, además de los protocolos de comunicación entre los elementos de red y el gestor centralizado de red, entre distintos gestores de red, y entre los gestores de red y los operadores humanos. Sin embargo, TMN presenta también muchos inconvenientes, destacando: su complejidad, que se basa en un sistema de computación distribuida relativamente antiguo (no soporta CORBA), que sólo contempla una extensión de CMIP como protocolo de gestión de red (no soporta SNMP), y que el protocolo de transporte de datos que emplea es X.25 (no admite TCP/IP). Por ello, y a la espera de que estas limitaciones sean solventadas en versiones posteriores, es empleado principalmente como marco de referencia para el desarrollo de herramientas de gestión de red.
TMN describe el paradigma gestor-agente, utilizado también por los principales modelos de gestión de red de nuestros días, como SNMP o CMIP. El software gestor, encargado del sondeo a los agentes, es instalado generalmente sobre una plataforma Unix, debido a sus altas prestaciones, robustez y fiabilidad; no obstante, actualmente se están incrementando las aplicaciones desarrolladas para sistemas operativos Linux, debido a sus altas prestaciones y bajo precio. La parte cliente es instalada sobre cada uno de los elementos de red a gestionar y consiste en un software agente, encargado de la comunicación con el gestor, y una base de datos con información de gestión o MIB (Management Information Base).
TMN define también una serie de funciones de gestión, distinguiendo claramente las que se encuentran en el gestor local y las que lo hacen en el gestor de red. El gestor local es el software encargado de la configuración de los elementos de red, y puede ser utilizado en las dependencias locales cuando es provisionado el nodo o en remoto cuando hay que cambiar algún parámetro de su configuración. El gestor de elemento es el software utilizado en el centro de supervisión remoto para realizar la gestión de fallos, configuración, contabilidad, rendimiento y seguridad (conocida como FCAPS en terminología TMN), sin considerar la topología de la red (enlaces, circuitos, etc.). El gestor de subred, integrado en muchas ocasiones en la misma plataforma que el gestor de elemento, es utilizado para manejar todas las áreas funcionales definidas en FCAPS, incluyendo la provisión de circuitos y la representación de la topología de la red.
Los gestores de subred actuales suelen estar programados sobre Java, pues presenta las mismas ventajas que otros lenguajes orientados a objetos empleados tradicionalmente en este tipo de desarrollos (principalmente C++), destacando, entre otras, facilitar notablemente la reutilización del software. Además, Java tiene ventajas añadidas, como una programación más sencilla e independencia del software desarrollado de la plataforma. Esto permite desarrollar más rápidamente y a menor coste sistemas de gestión de red, lo cual rendundará en menores costes en su precio final de ventas. El hecho de que el gestor desarrollado sea independiente de la plataforma, es algo muy atractivo, porque el usuario final puede elegir la plataforma en la que instalar el sistema (Unix, Linux, Windows), dependiendo, pricipalmente, del número de usuarios y elementos de red a soportar.
HTML (Hypertext Markup Language) constituye una de las partes esenciales en la WWW (World-Wide Web), siendo empleado para representar la información en la pantalla de un PC mediante enlaces de hipertexto que dirigen al usuario a otras fuentas de información. La principal limitación de HTML es que especifica de forma exacta la forma en que es mostrada la información recibida; no tiene conocimiento sobre el contenido de dicha información, tal como el significado de un campo de datos específico, por ejemplo. Esta deficiencia ha propiciado la introducción de XML (eXtensible Markup Language), como complemento a HTML. Al igual que HTML, XML es independiente de la plataforma. XML es un estándar para la descripción del contenido, no informa de la presentación de dicho contenido. En una situación como la actual, donde muchos operadores comparten la infraestructura de red o donde grandes clientes quieren tener un cierto control sobre la infraestructura de red que alquilan a los operadores, la interfaz Web es muy interesante para que dichos usuarios tengan una cierta capacidad de control (alarmas, rendimiento, inventario, etc.) de sus redes virtuales, conectándose al sistema de gestión de red del operador a través de Internet. Además, esta interfaz está siendo cada vez más utilizada en el desarrollo de gestores locales. Es decir, el agente ubicado en el elemento de red remoto implementa un servidor Web. Los usuarios se conectarán mediante un navegador Web instalado en su PC a dicho servidor, accediendo al menú con todas las operaciones que se pueden lanzar sobre el nodo. La ventaja de utilizar este mecanismo es que los usuarios no necesitan instalar nada adicional en su PC y que la aplicación de gestión puede ser lanzada desde cualquier tipo de sistema operativo.
Durante estos años se ha producido también un intenso debate acerca de qué protocolo de gestión de red acabará imponiéndose al resto. La utilización de distintos protocolos aumenta la complejidad y heterogeneidad de las redes, algo que no es en absoluto deseable. Los protocolos de gestión de red más importantes en estos momentos son: SNMP (Simple Network Management Protocol) y CMIP (Common Management Information Protocol). SNMP es un protocolo de la capa de aplicación que forma parte del conjunto de protocolos TCP/IP (Transmission Control Protocol / Internet Protocol) de Internet y, por su amplia utilización en redes empresariales, es considerado el estándar de facto en detrimento del protocolo CMIP (Common Management Information Protocol) de la familia de protocolos OSI (Open Systems Interconnection), más utilizado en las grandes redes de las operadoras de telecomunicación.
El primer protocolo que se usó fue SNMP en 1988. Se diseñó como algo provisional para "ir tirando" hasta que se desarrollara otro protocolo más elaborado. CMIP fue diseñado teniendo en cuenta SNMP, solucionando sus errores y fallos, convirtiéndose así en un gestor de red mucho más potente. No obstante, su gran complejidad desestimó su uso, sobre todo en las redes empresariales. Por otro lado, SNMP siguió evolucionando, dando lugar a: SNMPv2 en 1993 que define un mayor número de operaciones de protocolos, un conjunto mayor de códigos de error y más colecciones de datos; SNMPv2c en 1995 que añade como mejoras una configuración más sencilla y una mayor modularidad; y la última versión, SNMPv3 en 1997, que refuerza las prestaciones de seguridad (incluyendo autentificación, privacidad y control de acceso) y de administración de protocolo (con una mayor modularidad y la posibilidad de configuración remota). Cabe destacar que SNMPv3 no se trata de un estándar que reemplaza a SNMPv1 o SNMPv2, sino que define una serie de capacidades adicionales de seguridad y administración a ser utilizadas en conjunción con ellas.
La principal ventaja de SNMP respecto a CMIP para los programadores de herramientas de gestión de red es su sencillez, lo cual reduce mucho los costes y tiempo de desarrollo de las aplicaciones, así como de su posterior actualización. Existe tal cantidad de variables en CMIP que sólo los programadores más habilidosos son capaces de sacarlas todo su potencial. No obstante, mediante CMIP es posible desarrollar tareas que serían imposibles bajo SNMP.
De cara al usuario de las herramientas de gestión de red, CMIP tiene como principal desventaja que requiere unas 10 veces más recursos de red (capacidad de memoria y de procesador de los routers de la red de comunicaciones de datos y de los servidores del centro de gestión) que SNMP. Por otro lado, la implementación de los protocolos OSI sobre routers y plataformas de gestión es muy cara. En otras palabras, muy pocas redes empresariales son capaces de soportar una implementación completa de CMIP. El protocolo SNMP, además, opera sobre varios protocolos de transporte, originalmente y habitualmente sobre UDP (User Datagram Protocol), aunque actualmente también soporta, entre otros: OSI CLNS (ConnectionLess Network Service), AppleTalk DDP (Datagram-Delivery Protocol), y Novell IPX (Internet Packet Exchange). Sin embargo, SNMP es un protocolo que consume más ancho de banda que CMIP en entornos de red extendidos; debido a que trabaja mediante sondeo secuencial en vez de en modo conectado, lo cual no permite optimizar el tráfico. Además, SNMP, en su versión original, tampoco permite transferir eficientemente grandes cantidades de datos.
La limitación más importante de SNMP es una altísima vulnerabilidad a varias cuestiones de seguridad, como por ejemplo: modificación de información, alteración de la secuencia de mensajes, enmascaramiento de la entidad emisora, etc. En su versión original, cada gestor y agente es configurado con un nombre de comunidad, que es una cadena de texto plano. Los nombres de comunidad, enviados junto a cada comando lanzado por el gestor, sirven como un débil mecanismo de autentificación, ya que puesto que el mensaje no está cifrado, es muy sencillo que un intruso determine cuál es dicho nombre capturando los mensajes enviados a través de la red. Esta limitación, sin embargo, ha sido solventada por SNMPv3. CMIP, por trabajar en modo conectado, ofrece una mayor seguridad que SNMP.
Otra ventaja de SNMP respecto a CMIP, es que existen varias plataformas comerciales de gestión de red multifabricantes, como: OpenView de Hellwlett Packard (que es el producto más representativo con más de un 40% de cuota de mercado), SunNet de Sun Microsystems o NetView de IBM. Para integrar los productos de un determinado fabricante sobre la misma plataforma e interfaz gráfica, sólo es necesario compilar la MIB concreta proporcionada por dicho fabricante. Muchas veces, estas herramientas de gestión de red multifrabricante, suelen convivir con otras monofabricante, con el fin de aprovechar al máximo los desarrollos propios y particulares de cada proveedor. No obstante, cada vez es más habitual que tanto los gestores de red basados en SNMP como los basados en CMIP, incorporen la interfaz CORBA, para facilitar su integracion con otros sistemas de gestión de alto nivel. CORBA (Common Object Request Broker Architecture) es, básicamente, una arquitectura de programación distribuida diseñada para soportar objetos indpendientemente de su ubicación dentro de una red o máquina. En este caso, será la empresa que adquiera dichos gestores la encargada de realizar la integración de los productos de varios suministradores sobre una única plataforma, una tarea sumamente compleja.
Otra ventaja de SNMP es que en la actualidad es el protocolo de gestión de red más extendido y conocido. Además, la continua introducción de mejoras ha ido corriendo sus deficiencias e incrementado su funcionalidad. Por todo esto, la mayoría de los expertos opina que SNMP irá desplazando a CMIP en las grandes redes de gestión de las operadoras. TMN, que puede ser considerado una extensión del modelo CMIP, será utilizado como un marco de referencia a partir del cual desarrollar aplicaciones de gestión sobre SNMP.
