Ando unos días buscando información sobre el tema. El otro día me entró el gusanillo mientras pensábamos en nuevos recursos que añadir a nuestro catálogo de "plugins" para el middleware. Y es que, como ya sabéis (Y si no lo sabéis ahora es el momento), soy Ingeniero de Telecomunicaciones y de entre los temas que más me atrajo en mi dorada época estudiantil, las redes ópticas y las nuevas arquitecturas definidas sobre ellas.
Las redes ópticas actuales constan de un elevado número de capas que otorgan la capacidad de manejar perfiles determinados de información, lo que estaba tendiendo a redes demasiado específicas y difíciles de gestionar. Pero a algunos iluminados se les encendió la bombilla y pensaron que las redes debían simplicarse, evitando funcionalidades redundantes entre capas. Esto derivo hasta llegar a tener solo dos. Esto ha permitido desarrollar un plano de control común, y entre algunos protocolos de gestión, se encuentra GMPLS.
GMPLS es el resultado del trabajo entre Optical Internetworking Forum, Optical Domain Service Interconnect consortium y la Internet Engineering Task Force que pretende estandarizar un protocolo que pueda servir para todo tipo de tráfico. La clave se encuentra (y aquí os empezará a sonar a Grid) en la capacidad que tiene la capa de control de extender la topología de la red y la gestión del ancho de banda a lo largo de todas las capas para lograr un sistema eficiente que integre servicios y transporte.
Siguiendo con la filosofía Grid, GMPLS necesita tres componentes básicos para su correcto uso:
- Exploración de recursos: se obtiene información acerca de los recursos de red tales como conectividad o capacidad de los enlaces. Los mecanismos utilizados para diseminar esta información de estado se basan en una extensión del Internet Gateway Protocol (IGP).
- Selección de ruta: se utiliza para seleccionar una ruta apropiada a través de la red óptica inteligente en base a unas ciertas restricciones impuestas por el entorno y las limitaciones de la capa física.
- Gestión de ruta: incluye distribución de etiquetas, así como establecimiento, mantenimiento y terminación de ruta. Estas funciones se realizan por medio de un protocolo de señalización extendido como Resource Reservation Protocol for Traffic Engineering (RSVP-TE) o Constraint-routed Label Distribution Protocol (CR-LDP).
Estos tres componentes deben estar diseñados para su correcta utilización independiente entre si, permitiendo a las operadoras diseñar sus redes en consonancia con su modelo de negocio.
Aquí entra ThinkInGrid y nuestros componentes desarrollados. Queremos llegar a desarrollar un plugin capaz de virtualizar los datos provenientes de una red óptica. Esto debería permitir a empresas mucho más especializadas desarrollar productos o proyectos a medida para gestión de redes troncales:
- Uso de información descentralizada y distribuida por la red.
- Uso del plano de inteligencia artificial para optimizar y automatizar procesos de control y balanceo de carga.
- Monitorización de red añadiendo un plano de decisiones automatizadas.
- Desarrollo rápido y estandarizado de aplicaciones mediante el Framework.
- Creación de mecanismos de colaboración entre operadoras o empresas complementarias.
- Generación de nuevos modelos de negocio. Lo que permite una clara diversificación de servicios.
Bueno, creo que la cosa está clara. ¿Algún directivo de Telefónica, Wanadoo, Jazztel, Ono, etc en la sala y que quiera desarrollar la idea con nosotros? Las líneas de teléfono y de mail quedan abiertas :).


Entre línea y línea de código son comunes los 