ES2827245T3 - Sistemas y métodos para gestionar redes de comunicación multicapa - Google Patents

Abstract

Un sistema para mapear una red de comunicación multicapa que tiene una capa óptica y una capa de protocolo de Internet (IP), el sistema que comprende un controlador que se configura para ejecutar instrucciones para: recibir datos de tráfico de un primer contador de tráfico que se ubica en un puerto de la capa óptica y un segundo contador de tráfico que se ubica en un puerto de la capa IP; calcular un patrón de tráfico en el puerto de la capa óptica y un patrón de tráfico en el puerto de la capa IP a partir de los datos de tráfico que se reciben; comparar el patrón de tráfico en el puerto de la capa óptica con el patrón de tráfico del puerto de la capa IP; calcular un valor de coincidencia a partir de los patrones de tráfico comparados que representa la probabilidad de una coincidencia entre el puerto de la capa óptica y el puerto de la capa IP representativo de los puertos conectados; y determinar que el puerto de la capa óptica y el puerto de la capa IP se conectan al comparar el valor de coincidencia con un umbral fijo.

Description

DESCRIPCIÓN

Sistemas y métodos para gestionar redes de comunicación multicapa

Campo y antecedentes de la invención

La presente invención se relaciona con sistemas para gestionar redes de comunicación multicapa. Las modalidades de la presente invención se relacionan con una estructura para mapear interconexiones entre capas de la red de comunicación multicapa (mapeo entre capas) y gestionar fallas de comunicación en la red multicapa.

Hace décadas, el aumento de la demanda de servicios de telefonía impulsó el despliegue de redes de fibra óptica de alta capacidad. El posterior aumento de la demanda de servicios de Internet dio como resultado el aprovechamiento de dichas redes ópticas para la transmisión de paquetes IP en un esquema de comunicación de IP sobre óptica. Tal configuración multicapa utiliza los enrutadores IP para controlar las funciones de red y la red óptica para proporcionar rutas de comunicación de alto rendimiento entre los enrutadores IP.

La Figura 1 ilustra un ejemplo de una red multicapa que incluye una capa de Protocolo de Internet (IP) que se conecta sobre una capa óptica (por ejemplo, tecnología de Multiplexación por División de Longitud de Onda Densa DWDM). Las redes multicapa también pueden incluir una capa intermedia adicional de conmutadores de multiplexación por división de tiempo (TDM), tales como los que se definen por redes ópticas de transporte (OTN), o alternativamente, una capa de paquetes ópticos o Ethernet en lugar de una capa IP.

Dado que tales redes transportan cantidades extremadamente grandes de tráfico de comunicaciones y se distribuyen ampliamente en múltiples ubicaciones geográficas, cualquier falla de conectividad en las capas IP u ópticas puede afectar a una gran cantidad de usuarios. Como tal, las redes multicapa deben recuperarse rápida y eficientemente de una falla para brindar continuidad del servicio al usuario.

En una red multicapa de IP sobre óptica, un enlace entre enrutadores de la capa IP (Figura 1) se establece mediante una ruta óptica entre conmutadores ópticos (también denominados en la presente descripción como enrutadores o nodos ópticos) de la capa óptica (Figura 1). La falla de una ruta óptica puede restaurarse al reenrutar la ruta óptica alrededor de la falla (para restaurar la conectividad entre los enrutadores IP), mientras que la falla de una ruta IP puede restaurarse al enrutar el tráfico de comunicación a través de diferentes enrutadores IP.

Existen varios tipos de estructuras de restauración para recuperar la comunicación en caso de falla de comunicación óptica y/o de IP: (i) estructuras ópticas puras, en las que la decisión de restaurar las rutas ópticas se controla mediante la capa óptica; (ii) estructuras multicapa que están sesgadas hacia el uso de señalización distribuida para reenrutar conexiones ópticas en un momento de falla en función de decisiones que se toman de manera distribuida por los enrutadores IP; y (iii) estructuras multicapa controladas de forma centralizada que pueden reenrutar las conexiones al indicar al enrutador que vuelva a señalizar la conexión o al indicar a los nodos ópticos que realicen el reenrutamiento.

Una estructura óptica pura puede restaurar rápidamente el enrutamiento óptico; sin embargo, la ruta de restauración que establece la capa óptica puede no satisfacer las demandas de la capa IP; por ejemplo, su latencia podría ser demasiado alta para ser útil para la capa IP. Además, la restauración óptica solo es efectiva cuando la falla está en el dominio óptico y, como tal, no tiene en cuenta las fallas en la capa IP. Finalmente, cuando se repara la falla óptica y el sistema vuelve al modo normal (ruta de trabajo), la conmutación de la ruta de restauración a la ruta de trabajo reparada sin coordinación con la capa IP puede resultar en interrupciones de tráfico innecesarias.

Una estructura multicapa distribuida se basa en la señalización entre las capas IP y ópticas y asume que el enrutador IP tiene en cuenta las restricciones de las conexiones ópticas y es capaz de negociar estas restricciones con la capa óptica si las restricciones más estrictas resultan en rutas ópticas que no pueden usarse. Esto requiere el aprovisionamiento de múltiples "opciones de ruta" para el enrutador, lo que crea un proceso engorroso y un proceso de negociación rígido entre las capas, que sigue un orden fijo de restricciones cada vez más relajadas independientemente de la falla real. Este es un proceso que requiere mucho tiempo y genera pérdidas, ya que algunas opciones de ruta de restauración pueden ser irrelevantes para la falla real. La estructura multicapa distribuida también asume que la decisión de restaurar los enlaces IP a través de la capa óptica se determina estáticamente a priori. En la práctica, algunos enlaces podrían permanecer inactivos sin afectar el tráfico, mientras que otros deben restaurarse sobre la marcha, en base a las condiciones actuales del tráfico. Una estructura multicapa distribuida dirige mal las redes de múltiples proveedores y las redes de múltiples dominios debido a la falta de estándares entre proveedores y redes.

Una estructura multicapa que se controla de forma centralizada es ventajosa porque puede decidir qué conexiones restaurar y cómo restaurarlas en base a la comprensión global de la red y sus necesidades actuales; sin embargo, depende de la disponibilidad del controlador central, su sitio y servidor y la red de comunicaciones y, por tanto, es más vulnerable. La falta de disponibilidad del controlador central puede resultar en una pérdida de tráfico severa y una violación del contrato de servicio. Además, un controlador centralizado puede experimentar carga de señalización y carga de procesamiento durante una falla a gran escala, lo que provoca una recuperación lenta. Debido a estas limitaciones, los operadores de red se muestran reacios a adoptar soluciones de estructura multicapa.

En un esfuerzo por abordar las limitaciones de los enfoques de restauración descritos anteriormente, el presente inventor ha ideado una estructura para gestionar la restauración óptica sin impactar negativamente la comunicación a través de la capa IP tras la restauración y la posterior reversión a la ruta de trabajo.

El documento de la técnica anterior EP 1 089 521, describe una red de comunicaciones y un controlador que comprende un recolector de datos operable para recopilar datos que caracterizan la actividad de la red tanto en la Capa 3 como en al menos una Capa por debajo de la Capa 3.

Resumen de la invención

La invención se lleva a cabo como se describe en las reivindicaciones adjuntas.

Descripción general

De acuerdo con un aspecto de la presente invención, se proporciona un sistema para mapear una red de comunicación multicapa que tiene una capa de servidor y una capa de cliente, el sistema que comprende una estructura que se configura para comparar información que se obtiene de un primer contador de tráfico de un puerto de cliente con información que se obtiene de un segundo contador de tráfico de un puerto de servidor para determinar así si el puerto de cliente y el puerto de servidor están vinculados.

De acuerdo con características adicionales en las modalidades preferidas de la invención que se describen a continuación, la información se usa para modelar los recuentos de tráfico del puerto de cliente y el puerto de servidor durante un período de tiempo.

De acuerdo con aún otras características en las modalidades preferidas descritas, el modelo es una pendiente de los recuentos de tráfico del puerto de cliente y del puerto de servidor durante el período de tiempo.

De acuerdo con aún otras características en las modalidades preferidas descritas, la información se usa para construir un gráfico o patrón de recuentos de tráfico del puerto de cliente y del puerto de servidor durante un período de tiempo predeterminado.

De acuerdo con aún otras características en las modalidades preferidas descritas, el patrón incluye al menos un pico en el recuento de tráfico del puerto de cliente y el puerto de servidor, el pico que indica un punto máximo local en el gráfico de recuentos de tráfico.

De acuerdo con aún otras características en las modalidades preferidas descritas, la pendiente es de una línea que tiene una suma mínima de distancias a partir de los recuentos de tráfico durante el período de tiempo.

De acuerdo con aún otras características en las modalidades preferidas descritas, la línea se obtiene mediante el uso de un algoritmo de mínimos cuadrados.

De acuerdo con aún otras características en las modalidades preferidas descritas, la información se usa para determinar una diferencia promediada entre los recuentos de tráfico del primer contador de tráfico y el segundo contador de tráfico.

De acuerdo con otro aspecto de la presente invención, se proporciona un sistema para gestionar recursos en una red de comunicación multicapa, el sistema que comprende una estructura que se configura para identificar puertos de cliente de un solo conjunto de enlaces que se enrutan a través de la misma ruta de una capa de servidor y usar los puertos de cliente de manera intercambiable para reenrutar el tráfico.

De acuerdo con aún otras características en las modalidades preferidas descritas, los puertos de cliente tienen sustancialmente la misma capacidad.

De acuerdo con otro aspecto de la presente invención, se proporciona un sistema para gestionar una falla de comunicación en una red de comunicación multicapa, el sistema que comprende una estructura que se configura para: (a) identificar una falla de la ruta de comunicación en una capa de servidor de la red de comunicación multicapa, la falla de la ruta de comunicación que resulta en una falla de comunicación entre los nodos de una capa de cliente de la red de comunicación multicapa; (b) identificar rutas de restauración de la comunicación en la capa de servidor capaces de restaurar la comunicación entre los nodos de la capa de cliente; y (c) usar un régimen de restauración en base a un estado de la red para establecer selectivamente cada una de las rutas de restauración de la comunicación. De acuerdo con aún otras características en las modalidades preferidas descritas, el régimen de restauración establece un orden de establecimiento de cada una de las rutas de restauración de la comunicación.

De acuerdo con aún otras características en las modalidades preferidas descritas, el régimen de restauración establece un retardo de tiempo para establecer cada una de las rutas de restauración de la comunicación.

De acuerdo con aún otras características en las modalidades preferidas descritas, la estructura se configura además para evitar reenrutar el tráfico de comunicación en la capa de cliente.

De acuerdo con aún otras características en las modalidades preferidas descritas, la estructura se configura además para: (d) restaurar una porción de las rutas de restauración de la comunicación en la capa de servidor, restaurando así parcialmente el tráfico de comunicación entre los nodos de la capa de cliente.

De acuerdo con aún otras características en las modalidades descritas, la capa de servidor es una capa óptica y la capa de cliente es una capa IP.

De acuerdo con otro aspecto de la presente invención, se proporciona un sistema para gestionar una red de comunicación multicapa, el sistema que comprende una estructura que se configura para: (a) proporcionar nodos de una capa de servidor de la red de comunicación multicapa con instrucciones para restaurar una falla de comunicación en la capa de servidor; y (b) modificar periódicamente las instrucciones en respuesta al estado de la red de una capa de cliente de la red de comunicación multicapa.

De acuerdo con aún otras características en las modalidades preferidas descritas, las instrucciones se almacenan en los nodos de la capa de servidor o en un controlador central.

De acuerdo con aún otras características en las modalidades preferidas descritas, las instrucciones identifican una ruta de restauración de la comunicación para restaurar la falla de comunicación en la capa de servidor o las restricciones de la capa de cliente para configurar la ruta de restauración.

De acuerdo con aún otras características en las modalidades preferidas descritas, la capa de servidor es una capa óptica y la capa de cliente es una capa IP.

De acuerdo con otro aspecto de la presente invención, se proporciona un sistema para mapear una red de comunicación multicapa que tiene una capa de servidor y una capa de cliente, el sistema que comprende una estructura que se configura para: (a) eliminar un puerto de cliente de un enlace en un conjunto de enlaces múltiples que interconecta dos nodos de la capa de cliente, siendo la eliminación en condiciones en las que la capacidad del conjunto de enlaces múltiples supera la demanda de tráfico de comunicación entre los dos nodos de la capa de cliente, después de la eliminación; y (b) identificar un puerto de servidor de la capa de servidor que pierde la comunicación mapeando así el puerto de cliente al puerto de servidor.

De acuerdo con aún otras características en las modalidades preferidas descritas, la eliminación se efectúa al desconectar el puerto de cliente.

De acuerdo con aún otras características en las modalidades preferidas descritas, la pérdida de comunicación en el puerto de servidor se indica mediante un contador de tráfico del puerto de servidor.

De acuerdo con aún otras características en las modalidades preferidas descritas, el sistema identifica las condiciones.

De acuerdo con aún otras características en las modalidades preferidas descritas, el sistema crea las condiciones al añadir primero un nuevo enlace entre los dos enrutadores mediante el uso de interfaces de enrutador existentes y compartir la carga de tráfico a través del enlace.

De acuerdo con aún otras características en las modalidades preferidas descritas, el sistema crea un enlace adicional en el conjunto de enlaces múltiples aumentando así la capacidad del conjunto de enlaces múltiples para superar la demanda de tráfico de comunicación.

De acuerdo con aún otras características en las modalidades preferidas descritas, la capa de servidor es una capa óptica y la capa de cliente es una capa IP.

De acuerdo con otro aspecto de la presente invención, se proporciona un sistema para mapear una red de comunicación multicapa que tiene una capa de servidor y una capa de cliente, el sistema que comprende una estructura que se configura para: (a) mapear sitios de origen y destino en la capa de cliente y en la capa de servidor; y (b) identificar los puertos del nodo de cliente de la capa de cliente y los puertos del nodo del servidor de la capa de servidor que sirven a un par idéntico de sitios de origen y destino.

La presente invención aborda con éxito las deficiencias de las configuraciones actualmente conocidas al proporcionar un sistema que es capaz de mapear una red de comunicación multicapa y capaz de restaurar fallas de comunicación en redes multicapa mientras minimiza el impacto en la comunicación a través de la red durante y después de la restauración y recuperación de la red. El presente sistema no requiere un plano de control entre capas o una reconfiguración manual de los enrutadores de la capa de cliente y es operable con una amplia gama de proveedores/tipos de red.

A menos que se defina lo contrario, todos los términos técnicos y científicos que se usan en la presente descripción tienen el mismo significado que el que entiende comúnmente un experto en la técnica a la que pertenece esta invención. Aunque pueden usarse métodos y materiales similares o equivalentes a los que se describen en la presente descripción en la práctica o ensayo de la presente invención, a continuación, se describen métodos y materiales adecuados. En caso de conflicto, prevalecerá la especificación de la patente, que incluye las definiciones. Además, los materiales, métodos y ejemplos son solo ilustrativos y no pretenden ser limitantes.

La implementación del método y sistema de la presente invención implica realizar o completar tareas o etapas seleccionadas de forma manual, automática o una combinación de las mismas. Además, de acuerdo con la instrumentación y los equipos actuales de las modalidades preferidas del método y sistema de la presente invención, podrían implementarse varias etapas seleccionadas mediante hardware o software en cualquier sistema operativo de cualquier firmware o una combinación de los mismos. Por ejemplo, como hardware, las etapas seleccionadas de la invención podrían implementarse como un chip o un circuito. Como software, las etapas seleccionadas de la invención podrían implementarse como una pluralidad de instrucciones de software que ejecuta un ordenador mediante el uso de cualquier sistema operativo adecuado. En cualquier caso, las etapas seleccionadas del método y sistema de la invención podrían describirse como realizadas mediante un procesador de datos, tal como una plataforma informática para ejecutar una pluralidad de instrucciones.

Breve descripción de los dibujos

La invención se describe en la presente descripción, únicamente a modo de ejemplo, con referencia a los dibujos adjuntos. Con referencia específica ahora a los dibujos en detalle, se enfatiza que los detalles que se muestran son a modo de ejemplo y con el propósito de una discusión ilustrativa de las modalidades preferidas de la presente invención únicamente, y se presentan en la causa de proporcionar lo que se cree que es la descripción más útil y fácilmente comprensible de los principios y aspectos conceptuales de la invención. En este sentido, no se intenta mostrar los detalles estructurales de la invención con más detalle de lo necesario para una comprensión fundamental de la invención, la descripción tomada con los dibujos pone de manifiesto a los expertos en la técnica cómo las diversas formas de la invención pueden materializarse en la práctica.

En los dibujos:

La Figura 1 ilustra una red de comunicación multicapa de IP sobre óptica.

La Figura 2 es un diagrama de bloques que ilustra el presente sistema y su conectividad a los servidores de red multicapa.

Las Figuras 3a-d ilustran un conjunto de enlaces entre dos enrutadores IP y su ruta de restauración.

La Figura 4 ilustra implementaciones ejemplares del control centralizado multicapa de acuerdo con la presente invención.

Las Figuras 5-9 ilustran la restauración selectiva/escalonada de la falla de la ruta óptica de acuerdo con las enseñanzas de la presente invención.

La Figura 10 ilustra una red multicapa que muestra la conectividad entre las capas óptica e IP.

La Figura 11 ilustra un enfoque para mapear puertos IP a puertos ópticos en una red de comunicación multicapa. Las Figuras 12a-c ilustran otro enfoque para mapear puertos IP a puertos ópticos en una red de comunicación multicapa.

La Figura 13 ilustra la interacción entre los diferentes componentes de la presente red de múltiples dominios.

La Figura 14 ilustra la interacción entre los diferentes componentes en un solo sitio de una red multicapa.

La Figura 15 ilustra la interacción entre los diferentes componentes a lo largo de una conexión óptica en una red multicapa.

La Figura 16 ilustra un ejemplo de conectividad de puerto entre capas o entre dominios.

La Figura 17 ilustra una red que tiene varios enlaces ópticos de igual longitud.

Las Figuras 18a-c ilustran la ruta de servicio en la red de la Figura 17 (Figura 18a), una recuperación óptica de fallas a través de la ruta de capa IP existente (Figura 18b) y el enrutamiento del servicio a través de una ruta IP diferente (Figura 18c).

Las Figuras 19-21 son gráficos que ilustran tres enfoques para la correspondencia de puertos de acuerdo con las enseñanzas de la presente invención.

Descripción de las modalidades preferidas

La presente invención es un sistema que puede usarse para gestionar fallas de comunicación en redes de comunicación multicapa. Específicamente, la presente invención puede usarse para restaurar fallas de la ruta de comunicación en redes de IP sobre óptica.

Los principios y funcionamiento de la presente invención pueden entenderse mejor con referencia a los dibujos y descripciones adjuntas.

Antes de explicar al menos una modalidad de la invención en detalle, debe entenderse que la invención no se limita en su aplicación a los detalles expuestos en la siguiente descripción o ejemplificados mediante los Ejemplos. La invención es susceptible de otras modalidades o de ponerse en práctica o llevarse a cabo de diferentes formas en la medida en que esté dentro del alcance de las reivindicaciones adjuntas. Además, debe entenderse que la fraseología y la terminología que se emplean en la presente descripción tienen el propósito de describir y no deben considerarse limitantes.

Las redes de comunicación multicapa actuales incluyen una capa de cliente (por ejemplo, una capa IP) superpuesta sobre una capa de servidor preexistente (por ejemplo, una capa óptica). Dado que estas redes no se diseñaron desde cero como una solución integrada, la gestión de redes multicapa requiere un control independiente sobre cada capa de red, a menudo sin tener en cuenta los efectos de los cambios de configuración en una capa sobre la comunicación a través de la capa conectada. Aunque las herramientas de gestión para controlar las capas de servidor y de cliente (por ejemplo, HP OpenView) pueden, en teoría, proporcionar una solución de gestión más integrada, dichas herramientas se limitan inherentemente por las diferencias en los equipos de los proveedores en las capas de servidor y de cliente y la renuencia de los operadores a modificar las configuraciones de la capa IP.

Al tiempo que reduce la presente invención a la práctica, el presente inventor creó un sistema que puede proporcionar una restauración centralizada de fallas de comunicación en redes multicapa sin requerir necesariamente el control sobre los enrutadores de la capa de cliente.

Por tanto, en efecto, el presente sistema proporciona una gestión centralizada mediante el control de la capa de servidor. Para brindar tal funcionalidad, el presente sistema se configura para:

(i) mapear la interconectividad entre los nodos de la capa de servidor y los nodos de la capa de cliente para definir rutas de comunicación entre la capa de servidor específica y los puertos de la capa de cliente;

(ii) predefinir rutas de comunicación de la capa de servidor para restaurar una falla de comunicación de la capa de servidor o de la capa de cliente en base al estado de la red y (i);

(iii) predefinir el orden de restauración para las rutas de comunicación de la capa de servidor o el retardo antes de intentar la restauración;

(iv) cambiar la configuración de restauración predefinida cuando cambian las condiciones de tráfico;

(v) determinar las rutas de restauración y su orden en base a la simulación global del comportamiento de la red y las restricciones globales, tales como la latencia de extremo a extremo o el soporte necesario para múltiples fallas simultáneas;

(vi) configurar umbrales para el número mínimo de enlaces IP entre un par de enrutadores que deben estar activos antes de que el tráfico comience a fluir entre ellos; y

(vii) determinar la latencia máxima permitida de un enlace IP, dada una latencia de extremo a extremo que configura el usuario, y usarla para definir las restricciones de la ruta de restauración.

Tales características del presente sistema pueden proporcionar la siguiente funcionalidad:

(a) restauración de bajo costo de fallas de comunicación en las capas de servidor o de cliente;

(b) restauración del servicio más rápida en comparación con otros enfoques que no controlan el orden de restauración; (c) reducción de la interrupción del tráfico durante el proceso de restauración en comparación con otros enfoques; (d) reducción de la interrupción del tráfico durante el proceso de reversión en comparación con otros enfoques; (e) soporte para redes de múltiples proveedores que no soportan la señalización cliente-servidor (UNI); y

(f) garantía de SLA durante fallas con respecto a la latencia de extremo a extremo y otras restricciones a nivel de servicio.

Estas funciones pueden proporcionarse mediante una estructura (software de aplicación específica) que se ejecuta en un servidor conectado a la red de comunicación multicapa de alta velocidad a través de una red de baja velocidad dedicada con fines de gestión y control, que a menudo se denomina como "red de comunicación de datos" (DCN).

La Figura 2 es un diagrama de bloques que ilustra el presente sistema al que se hace referencia en la presente descripción como sistema 10. El sistema l0 incluye el servidor 12 (por ejemplo, un servidor blade HP) que incluye un controlador central 13 y una estructura 14. El servidor 12 es parte de, o está en comunicación con la red de comunicación multicapa 16 a través de una red de gestión/control 15. La red de comunicación multicapa 16 incluye una capa de servidor 18 (por ejemplo, óptica) que se conecta a una capa de cliente 20 (por ejemplo, IP). La capa de servidor 18 incluye enrutadores de servidor 22 (por ejemplo, enrutadores ópticos) que se interconectan a través de rutas de comunicación 24 (por ejemplo, fibras ópticas). Los enrutadores 22 incluyen puertos 26 que se conectan a los puertos 28 de los enrutadores del cliente 30 (por ejemplo, enrutadores IP) para establecer enlaces ópticos 32 entre los enrutadores del cliente 34.

Con referencia a la Figura 4, la estructura 14 puede incluir un módulo de orquestación que incluye una base de datos que representa la red multicapa, sus nodos, enlaces y estadísticas de tráfico. También incluye una base de datos de mapeo que captura cuál puerto de cliente se mapea a cuál puerto de servidor. Este orquestador tiene interfaces de software para múltiples adaptadores, cada uno de los cuales se adapta a un formato específico del proveedor de la "interfaz ascendente" (NBI) del controlador central que normalmente controla el equipo de este proveedor. El orquestador interactúa con varias aplicaciones multicapa mediante el uso de otra interfaz de software.

El sistema 10 funciona continuamente para restaurar las fallas de comunicación y para proporcionar el monitoreo y la gestión de la red multicapa 16 durante el comportamiento normal de la red. Como se usa en la presente descripción, "fallas de comunicación" se refiere a cualquier comportamiento anormal de la red (ralentización de la comunicación, pérdida de paquetes, evento de desactivación de enlace o aumento de la tasa de error en un enlace) que provoca una falla parcial o total del equipo de comunicación (por ejemplo, fibras de comunicación, mecanismos ópticos, enrutadores, etcétera).

Por tanto, de acuerdo con un aspecto de la presente invención, se proporciona un sistema para gestionar una falla de comunicación en una red de comunicación multicapa. La red multicapa puede ser cualquier red de comunicación compuesta por al menos una capa de servidor (por ejemplo, una capa de comunicación óptica) y una capa de cliente (por ejemplo, una capa de comunicación IP).

El sistema de la presente invención se configura para identificar una falla de la ruta de comunicación en la capa de servidor que da como resultado una falla de la ruta de comunicación entre los nodos de la capa de cliente. Tal falla puede provocase por el corte de una fibra óptica, falla del equipo de comunicación, tal como enrutadores de la capa de servidor, tales como multiplexores de adición/supresión reconfigurables (ROADM) o puertos o amplificadores ópticos. La identificación de tal falla se efectúa normalmente tanto por la capa de cliente como por la capa de servidor y se reporta al sistema de comunicación y a un controlador central del presente sistema.

Una vez que se identifica la falla de la ruta de comunicación y se mapea a enrutadores y puertos específicos de la capa de cliente y de servidor (el mapeo se describe más adelante en la presente descripción), el sistema identifica rutas de restauración de la comunicación en la capa de servidor que son capaces de restaurar la comunicación entre los nodos afectados de la capa de cliente. Por ejemplo, en una red multicapa que tiene una capa de servidor óptico, tales rutas de restauración son rutas ópticas alternativas que sirven a los enrutadores de la capa de cliente (IP) afectados.

Una vez que se identifican las rutas de restauración apropiadas en la capa de servidor, el presente sistema aplica un régimen de restauración en base a un estado de la red para establecer selectivamente cada una de las rutas de restauración de la comunicación. El régimen puede aplicarse sobre la marcha después de una falla o puede preestablecerse y almacenarse en los enrutadores de la capa de servidor (como se describe a continuación con respecto al comportamiento normal de la red) para activarse después de una falla.

Como se usa en la presente descripción, "estado de la red" se refiere a la configuración de nodos y puertos, las condiciones actuales del tráfico, las rutas ópticas actuales que se han establecido en la red, las fallas actuales y cualquier otro dato que afecte el comportamiento de la red.

La restauración de una falla de comunicación en una red multicapa se efectúa mediante el presente sistema mediante varias etapas, opcionalmente superpuestas cronológicamente. La descripción a continuación describe la restauración en una red de IP sobre óptica; sin embargo, tenga en cuenta que tal restauración también se aplica a otras configuraciones de red multicapa, que incluye las redes multicapa que tienen más de dos capas.

Cuando una ruta óptica que enlaza dos enrutadores IP (Figura 3a) falla (Figura 3b), la capa IP detecta la falla resultante e intenta reenrutar todo el tráfico a través de las rutas de comunicación viables más cortas. En la actualidad, una capa IP típica se configura con suficiente capacidad de comunicación para gestionar tales fallas sin causar congestión. Sin embargo, una red más eficiente en el futuro que se diseña para depender de la restauración multicapa no tendrá la capacidad de comunicación requerida para manejar tales fallas y puede surgir una congestión si la falla ocurre durante las horas pico de tráfico. Esto solo afecta al tráfico de baja prioridad; el tráfico de alta prioridad se recuperará ya que la red proporciona capacidad a dicho tráfico por diseño.

El presente sistema normalmente no interferirá con los intentos de reenrutar la comunicación en la capa IP, pero posteriormente realizará la restauración a través de la capa óptica, eliminando así la congestión temporal para el tráfico de baja prioridad. Como se mencionó anteriormente en la presente descripción, una modalidad del presente sistema proporciona a los enrutadores ópticos con instrucciones (una "ruta alternativa" o régimen de restauración que se dicta mediante datos de configuración) que se almacenan en enrutadores ópticos y se actualizan cuando cambian las condiciones. Tales datos de configuración (que pueden empaquetarse como un archivo) pueden proporcionarse sobre la marcha e incluyen instrucciones sobre la ruta de restauración más adecuada en la capa óptica y el tiempo/orden de restauración de cada ruta. La capa óptica restaurará las rutas ópticas que se designan como restaurables ópticamente en un orden determinado mediante las instrucciones que proporciona el presente sistema (las Figuras 3c-d ilustran la restauración escalonada de rutas).

El tiempo/orden de restauración puede efectuarse mediante el uso de mecanismos de plano de control bien conocidos, por ejemplo, mediante el uso de Conmutación Generalizada de Etiquetas Multiprotocolo (GMPLS) o mediante un controlador central del sistema óptico. Normalmente, el sistema óptico hace cumplir el orden al introducir un retardo (de varios segundos) en la restauración de algunas de las rutas ópticas.

Alternativamente, el presente sistema puede controlar directamente el proceso de restauración después de una falla. Tal control directo puede efectuarse al emitir comandos a los elementos de la red directamente o a los controladores de los elementos de la red de la ruta de restauración y el orden de restauración.

El presente sistema puede efectuar varios escenarios de restauración:

(i) El controlador central del presente sistema emite comandos al controlador de la capa óptica antes de que ocurra una falla (régimen de restauración previamente aprovisionado), que inmediatamente emite comandos a los enrutadores ópticos (normalmente se llaman ROADM). Durante la falla, los enrutadores ópticos restauran de forma autónoma una ruta de comunicación;

(ii) el controlador central emite los comandos al controlador de la capa óptica antes de que ocurra una falla. El controlador de la capa óptica no emite de inmediato ningún comando a los enrutadores ópticos, sino que solo lo hace después de que ocurre la falla;

(iii) el controlador central emite los comandos al controlador de la capa óptica después de una falla. El controlador de la capa óptica envía inmediatamente los comandos a los enrutadores ópticos (régimen de restauración posterior a la falla);

(iv ) El controlador central emite los comandos directamente a los enrutadores ópticos antes de que ocurra una falla. Durante la falla, los enrutadores ópticos restauran la ruta de forma autónoma; o

(v) el controlador central emite los comandos a los enrutadores ópticos después de la falla.

El controlador puede decidir no restaurar otros enlaces en el conjunto ya que las condiciones de tráfico actuales no requieren su restauración. Estos enlaces no se restaurarán ópticamente y, por lo tanto, fallarán.

El orden de restauración es importante para asegurar una rápida recuperación de un estado de tráfico congestionado a un estado no congestionado. Esto se debe a que algunos enlaces tienen un mayor impacto en la recuperación del tráfico que otros enlaces. Por ejemplo, la falla de enlaces que normalmente transportan una cantidad significativa de tráfico puede provocar que este tráfico se desvíe a otros enlaces que tienen pocos recursos libres, lo que resulta en congestión. La recuperación temprana de estos enlaces hará que el tráfico vuelva a ellos, eliminando así la congestión. Por otro lado, si los enlaces que llevan una carga ligera se recuperan primero, su recuperación no reducirá significativamente la congestión. Esto se demuestra en la red que se muestra en la Figura 5, en la que dos partes de una red IP (simbolizadas por nubes) se conectan a través de 3 enlaces. El tráfico actual en cada enlace se captura con el primer número que se muestra junto al nombre del enlace en la figura, mientras que la capacidad restante que no se usa se captura con el segundo número (por ejemplo, la Enlace 2 soporta actualmente 80 Gbps, mientras que tiene otros 20 Gbps de capacidad que permanecen sin usarse). Cuando ocurre una falla que afecta a dos de los enlaces en la Figura 6, todo el tráfico se enruta sobre el Enlace 1, que transporta tráfico de 150 Gbps sobre un enlace de 100 Gbps, lo que provoca una congestión temporal significativa del tráfico del 150 % y la posterior pérdida de tráfico. Cuando el Enlace 3 se recupera mediante la capa óptica, la capa IP puede configurarse de una manera que provoca que el tráfico del Enlace 2 continúe enrutado por el Enlace 1 como se muestra en la Figura 7, en cuyo caso la congestión en el Enlace 1 se reduce a 130 % pero todavía está presente, y esto puede continuar durante unos pocos minutos hasta que el Enlace 2 se recupere ópticamente y la congestión desaparezca. El presente sistema puede elegir un orden de restauración diferente, en el que el Enlace 2 se recupera primero, eliminando así la congestión del Enlace 1 como se muestra en la Figura 8.

Además, restaurar el tráfico en el orden incorrecto puede provocar un mayor nivel de congestión e incluso la pérdida de tráfico de alta prioridad. Por ejemplo, si un enlace restaurado habilita una ruta más corta en la red para una cantidad significativa de tráfico reenrutado, este enlace puede convertirse en un cuello de botella antes de que se restauren otros enlaces y provocar una congestión más significativa que sin él. Teniendo en cuenta el ejemplo de la Figura 5 nuevamente, y la falla en la Figura 6, si la restauración óptica elige restaurar el Enlace 3 primero, y la capa IP se configura de una manera que provocará que el tráfico del Enlace 2 ahora se reenrute a través del Enlace 3 como se muestra en la Figura 9, se producirá una congestión excesiva del 250 % en el Enlace 3, lo que provocará un daño más significativo y, potencialmente, la pérdida de tráfico de alta prioridad.

El presente sistema puede cambiar de vez en cuando el régimen de restauración previamente aprovisionado debido a cambios en los patrones de recuento de tráfico de la capa IP o debido a cambios en el uso de recursos o la topología de la capa óptica. En este caso, el presente sistema reaprovisionará la capa óptica con el nuevo régimen, un proceso que normalmente no tendrá ningún impacto en el tráfico actual.

La capa óptica puede fallar en la restauración automática de algunos enlaces que establece el régimen de restauración previamente aprovisionado mediante el presente sistema, debido a la falta de recursos. También puede fallar al restaurar enlaces debido a problemas de control en la capa óptica. De cualquier manera, normalmente comunicará tal falla de restauración al presente sistema (por ejemplo, disparará una alarma en el controlador central). Alternativamente, el controlador central puede sondear para ver si se han restaurado los enlaces. Este sondeo es importante en los casos donde, por ejemplo, la restauración óptica intenta restaurar una ruta repetidamente sin éxito. En tal caso, el control central emitirá una solicitud a la capa óptica para abortar el proceso de restauración. Otro ejemplo es cuando la capa óptica no se da cuenta de que la ruta ha fallado y no intenta restaurarla, por ejemplo, cuando la señal se degrada, pero no está completamente ausente. En este caso, la capa IP emitirá una alarma de que el enlace está desactivado, pero la capa óptica no emitirá alarmas.

Dado que el controlador central conoce el uso de recursos en la capa óptica y del estado general de la red, puede decidir si la falla no puede restaurarse ópticamente (por ejemplo, una falla en el puerto del enrutador), en cuyo caso puede invocar diferentes mecanismos de restauración para restaurar la capacidad (tal como la restauración de puertos multicapa, como se enseña en Gerstel y otros, IEEE Communications Magazine, enero de 2014).

Si la falla es restaurable ópticamente, pero no bajo el régimen de restauración previamente aprovisionado mediante el presente sistema, el sistema aprovisiona una ruta de restauración con un nuevo conjunto de restricciones que pueden seguir siendo adecuadas para la capa IP, pero más relajadas que el régimen de restauración original. Dado que el controlador central conoce el estado de la red y las necesidades de comunicación en tiempo real de la capa IP, puede decidir relajar las restricciones de la ruta óptica sobre la marcha. También puede elegir un conjunto de restricciones que sean adecuadas para el tipo específico de falla, una función que no puede realizarse mediante el uso de enfoques de restauración distribuida de la técnica anterior.

Por lo tanto, el presente sistema puede tratar de manera efectiva fallas complejas mediante el uso de un control central y diferir la restauración de fallas simples al plano de control distribuido de la red, que no puede lidiar efectivamente con fallas complejas, tales como, por ejemplo, fallas duales de enlaces.

Los enlaces fallidos que no se han restaurado por el presente sistema (por ejemplo, el segundo enlace en el conjunto que se muestra en la Figura 3d) se identifican y catalogan por el controlador central mediante alarmas o sondeos. El controlador central puede decidir restaurar primero los otros enlaces de este conjunto y retardar la restauración de este enlace pocos minutos. En algunos casos, dado que el controlador central restaura rápidamente el primer enlace de este conjunto, el impacto de una restauración más lenta del segundo enlace será aceptable. La decisión del controlador central de restaurar el segundo enlace puede basarse en el conocimiento del tráfico que atraviesa el enlace, ya sea antes de la falla o en base a la congestión en el enlace restaurado después de la falla. También puede basarse en la disponibilidad de recursos de repuesto en la capa óptica y puede retardarse intencionalmente para garantizar que todo el tráfico crítico ya esté restaurado, antes de intentar restaurar enlaces menos críticos (para que el último no bloquee la restauración del primero).

Algunos de los enlaces pueden no restaurarse mediante el presente sistema debido a la falta de demanda, es decir, las condiciones actuales del tráfico de la capa IP no requieren que dichos enlaces estén activos. Sin embargo, si en un momento posterior el tráfico aumenta hasta un punto que requiere la activación de estos enlaces, el controlador central, que conoce de este aumento en el tráfico, restaurará selectivamente dichos enlaces en función de las demandas.

La decisión de la ruta que se usa para restaurar un enlace IP fallido se basa en las restricciones impuestas a la ruta de restauración por la capa IP o la capa óptica. Estas restricciones pueden ser diferentes entre la ruta normal y la ruta de restauración, sin embargo, cambiar las restricciones de la ruta a menudo es imposible para las rutas que son restauradas automáticamente por la capa óptica (enfoque (a) - sin la colaboración de la capa IP). Tales rutas restauradas automáticamente no obedecen a ninguna restricción (un enfoque que puede ser demasiado indulgente y no se ajusta a las necesidades de la capa IP), o usan las mismas restricciones que se usan para la ruta normal (un enfoque que puede ser demasiado estricto y no se adecúa a lo que puede hacer la capa óptica). Por esta razón, los enfoques de la técnica anterior se basan en el enrutador para saber cómo relajar las restricciones para la ruta óptica, pero esto sigue siendo insuficiente, ya que estas reglas de relajación se aprovisionan estáticamente en el enrutador.

En algunos casos, el controlador central no solo determinará las restricciones que la ruta debe obedecer, sino que también determinará los detalles de la ruta, es decir, la ruta explícita en la capa óptica, la longitud de onda específica que se usará para la ruta de restauración y los regeneradores específicos que se usan a lo largo de la ruta. Esto se efectúa para evitar condiciones de carrera (recursos de en longitud de onda y regeneración) y cálculos excesivos durante una falla. Esta información puede calcularse mediante el controlador central directamente o al consultar un elemento de cálculo de ruta (PCE). Si tales detalles se aprovisionan previamente en la capa óptica a priori, el controlador central puede alterar estos detalles en base a las condiciones cambiantes de la red.

El controlador central también puede determinar la prioridad de restauración de cada conexión óptica, controlando así el orden de las actividades de restauración. Si los enlaces IP se restauran en el orden incorrecto, pueden producirse pérdidas de tráfico transitorias no deseadas. Esta es otra ventaja del presente sistema sobre los enfoques de la técnica anterior. Por ejemplo, un conjunto de enlaces que incluye tres enlaces (Figura 3a) fallará después de una falla de comunicación óptica (Figura 3b). En consecuencia, el tráfico que transporta el conjunto se reenrutará rápidamente a otra parte de la red IP y se recuperará. Si el tráfico de alta prioridad (crítico) ocupa más de un enlace de este conjunto y la restauración óptica restaura temporalmente solo un enlace (Figura 3c), el tráfico de alta prioridad se reenrutará por la capa IP para usar este enlace (ya que está en la ruta más corta para este tráfico) provocando así una congestión y pérdida de tráfico no deseadas. Solo la restauración del segundo enlace del conjunto (Figura 3d) restaurará el tráfico de alta prioridad a la normalidad. Para evitar este escenario, el controlador central proporcionará datos de configuración en los enrutadores ópticos indicándoles que no activen el conjunto a menos que dos de los tres enlaces estén activos. La capacidad de activar el conjunto solo cuando un número específico de enlaces está activo es una característica de los enrutadores actuales; sin embargo, esta configuración es estática y no puede cambiarse cuando el tráfico de alta prioridad ya no requiere dos enlaces.

El presente sistema también puede manejar escenarios aún más complejos. Por ejemplo, el presente sistema puede dictar un orden de restauración a través de enlaces que conectan diferentes enrutadores (no en el mismo conjunto) en base a la simulación del comportamiento de la red después de la recuperación de cada enlace. Como se mencionó anteriormente, el orden normalmente puede hacerse cumplir a priori al establecer la prioridad de restauración de las conexiones.

El esquema de restauración descrito en la presente descripción puede extenderse a una red con más de dos capas. Como se describió anteriormente, el controlador central del presente sistema decide para cada nodo IP (enrutador) si el tráfico se restaura automáticamente en la capa óptica o no. Dado que la capa IP siempre restaura el tráfico automáticamente, la decisión de no restaurar ópticamente el tráfico es equivalente a la decisión de restaurarlo en la capa IP. Por lo tanto, el controlador central decide de manera efectiva para cada enlace en qué capa debe restaurarse el tráfico en caso de falla del enlace. Por lo tanto, en una red de tres capas, el controlador central puede decidir que el tráfico se restaurará en la capa superior, la capa intermedia o la capa inferior. De acuerdo con las condiciones del tráfico, el controlador central puede decidir cambiar la capa en la que se restaura el tráfico. Además, el controlador central puede decidir restaurar la capacidad adicional en diferentes capas después de una falla.

Después de la reparación del enlace óptico fallido (por ejemplo, la reparación física de una fibra óptica cortada), la red debe volver a su estado normal. Como tal, las conexiones ópticas que se reenrutaron a través de sus rutas de restauración deben reenrutarse a la ruta más corta, anterior a la falla, que es normalmente (pero no siempre) la ruta original antes de la falla.

Reenrutar una ruta óptica sin coordinación con la capa IP implica un impacto de tráfico en la capa IP, ya que este proceso desactivará los enlaces IP y provocará una repentina convergencia de la topología IP. Como resultado, los operadores no permitirán que tales eventos sucedan automáticamente, lo que resultará en un funcionamiento más complejo y estados anormales prolongados de la red.

El presente sistema trata eficazmente este problema mediante una coordinación cuidadosa entre las capas de la red para minimizar el impacto de este proceso.

Cuando se repara la falla de comunicación, el controlador central identificará el enlace óptico recién reparado (normalmente mediante la desaparición de la condición de alarma que se activó por la falla original). El controlador central considerará las condiciones actuales del tráfico (estado de la red) y decidirá si la red puede tolerar una interrupción temporal de ciertos enlaces, al simular el comportamiento de la red bajo esta interrupción.

Si tal interrupción es posible sin causar congestión, el controlador central elegirá un enlace IP, descargará lentamente el enlace al aumentar el costo de la métrica de enrutamiento para el enlace (se denomina "calcular el costo del enlace" y es una práctica manual común hoy en día cuando se realiza el mantenimiento de un enlace).

Una vez que el enlace se descarga, el controlador central lo eliminará de los enlaces IP activos y ordenará a la capa óptica que se reenrute a la ruta original (antes de la falla) o a la mejor ruta disponible en ese momento (esto puede basarse en la política de los operadores). Una vez que el enlace esté activo, el controlador central restablecerá el servicio a través de esta ruta óptica.

Como se mencionó anteriormente en la presente descripción, el presente sistema también gestiona la red durante el funcionamiento normal de la red.

Durante el funcionamiento normal de la red (no se detecta ninguna falla), el controlador central monitorea la red y, de vez en cuando, cambia varias propiedades de los enlaces ópticos y los puertos IP al proporcionar datos de configuración a los nodos de red y/o sus controladores.

Por ejemplo, el controlador central determina qué enlaces IP deben restaurarse automáticamente mediante la capa óptica, sobre qué ruta deben restaurarse y en qué orden deben restaurarse.

Para decidir qué enlaces IP deben restaurarse, el controlador central monitorea el tráfico en cada adyacencia IP - uno o más enlaces IP, que se configuran normalmente como un "conjunto de enlaces". Cada enlace conecta un par de puertos específicos de enrutadores IP conectados y soporta una ruta óptica (Figura 3a).

Por ejemplo, el controlador central puede aprovisionar previamente un régimen de restauración a la capa óptica para restaurar sólo un enlace de un conjunto en los casos en que dicho enlace único sea suficiente para soportar el tráfico crítico. Esto puede afectarse por la preconfiguración del "extremo de cabecera de ruta", que es el nodo óptico en un punto extremo de la ruta óptica. Como resultado, la red se comportará como se muestra en la Figura 3c.

Si el tráfico crítico supera la capacidad de un solo enlace, el controlador central reaprovisionará un nuevo régimen de restauración a la capa óptica, para restaurar automáticamente un segundo enlace del conjunto de enlaces. Como resultado, la red se comportará como se muestra en la Figura 3d.

Al cambiar el número de enlaces preconfigurados para restaurarse ópticamente, el controlador central también debe aprovisionar a los enrutadores IP en ambos extremos con el número mínimo de enlaces necesarios para llegar a la adyacencia. Este atributo existe actualmente en los enrutadores de núcleo, por ejemplo, en el enrutador CRS-1 de Cisco. Se aprovisionará para 1 en el primer caso (Figura 3c) y 2 en el último caso (Figura 3d).

Por el contrario, si el tráfico crítico está por debajo del umbral del enlace, el controlador central puede reconfigurar la capa óptica para no restaurar el segundo enlace del conjunto.

La decisión de restaurar selectivamente uno o más enlaces ópticos en un conjunto se basa en la medición de la carga de tráfico del conjunto y en técnicas de umbral estándar que se basan en la histéresis y se efectúa mientras el enlace está activo sin un impacto en el tráfico.

Como se mencionó anteriormente en la presente descripción, el presente sistema se configura también para mapear la conectividad entre la capa de servidor y de cliente. El mapeo puede efectuarse mediante una estructura que se ejecuta en un servidor que se conecta a la red de comunicación multicapa.

Las Figuras 11-12c ilustran varios enfoques de mapeo que pueden usarse por el presente sistema.

Un enfoque para mapear puertos de capa óptica e IP se basa en comparar el origen y el destino de los enlaces en la capa IP y las conexiones en la capa óptica.

Con referencia a la Figura 11, el mapeo aproximado de puertos entre el enrutador IP A y el enrutador óptico 1 en la ciudad X puede deducirse siguiendo la ruta de las 3 conexiones ópticas entre el enrutador óptico 1 y 3, y percatándose de que hay 3 enlaces IP entre el enrutador A y B con los mismos pares de ciudades X e Y. Tal mapeo aproximado (o "difuso") es a menudo suficiente para el funcionamiento del presente sistema, o puede usarse como una forma de restringir las elecciones de configuración manual del operador - al ofrecerles opciones solo desde dentro del subconjunto relevante. Además, cuando la ruta óptica de estos enlaces es la misma (como suele ser el caso), el sistema puede calcular el impacto de una falla de un enlace óptico a lo largo de esa ruta sin conocer el mapeo exacto, ya que todos estos enlaces fallarán al mismo tiempo. Esto permite al sistema evaluar la capacidad de respaldo requerida en la capa IP o en la capa óptica y realizar el análisis de impacto para el usuario. Además, si la capacidad de los enlaces en el conjunto es la misma, entonces el sistema puede evaluar además el impacto de una falla de un solo puerto en el conjunto para propósitos del análisis de impacto, o el impacto de la falla de K fuera de N enlaces del conjunto (por ejemplo, si falla un componente que soporta solo los enlaces K del conjunto).

Las Figuras 12a-c ilustran un enfoque para mapear con mayor exactitud un puerto en un enrutador IP A a un puerto en el enrutador óptico 1 que se basa en la medición del tráfico en el conjunto de enlaces entre los enrutadores IP A y B. Cuando la demanda de tráfico es baja, un miembro del conjunto puede eliminarse sin impactar negativamente la comunicación (Figura 12a). Esto puede efectuarse mediante la configuración de un puerto de enrutador IP no mapeado A1 y un puerto de enrutador IP no mapeado B1 (los enrutadores conocen el mapeo entre A1 y B1). El enlace óptico (láser) puede luego apagarse en el puerto A1 para observar qué puerto óptico envía una alarma por pérdida de luz (se muestra el puerto 11). Esto permite mapear el puerto del enrutador IP al puerto óptico. Apagar el láser en el puerto óptico remoto para la misma conexión (se muestra el puerto 31) proporciona una indicación similar para el puerto del enrutador B1.

El mapeo entre los puertos 11 y 31 se conoce por la capa óptica y, por lo tanto, este proceso garantiza que solo 1 enlace entre los enrutadores se afecte, incluso durante las configuraciones incorrectas. Este procedimiento establece el mapeo entre el puerto A1 y el puerto 11 y entre el puerto B1 y el puerto 31. Ahora, en B1, el láser se apaga hacia el puerto 31. Si el puerto B1 se conecta a otro puerto óptico, digamos el 32, entonces el 32 emitirá una alarma, descubriendo la discrepancia, pero esto todavía solo afectará a un solo enlace IP bidireccional, entre el puerto A1 y B1.

Si bien el orden descrito anteriormente asegura una interrupción mínima, también pueden practicarse órdenes de acciones menos óptimas mediante el uso de la presente invención. Una vez que se descubre el mapeo completo entre los puertos A1 y 11 y entre los puertos B1 y 31, los puertos se encienden otra vez.

Un enfoque alternativo se basa en puertos de enrutador de repuesto que se conectan a puertos ópticos de repuesto, como se muestra en la Figura 12b. En este caso, puede establecerse un enlace de repuesto entre los enrutadores A y B mediante la configuración de una conexión entre los puertos ópticos 14 y 34, como se muestra en la Figura 12c. Una vez que el enlace de repuesto está activo, se agrega al conjunto de enlaces entre los enrutadores A y B, seguido de la eliminación del enlace entre A1 y B1. Una vez que se elimina el enlace, se sigue el proceso de descubrimiento del mapeo antes mencionado. La ventaja de este enfoque es que puede realizarse incluso cuando el tráfico a través de un conjunto de enlaces no permite eliminar un enlace.

Aún otro enfoque para el mapeo puede efectuarse eliminando un puerto de cliente de un enlace en un conjunto de enlaces múltiples que interconecta dos nodos de la capa de cliente. Dicha eliminación, la cual puede efectuarse mediante la desconexión de un puerto o al poner el puerto fuera de servicio, se realiza bajo condiciones en las cuales la capacidad del conjunto multienlace supera la demanda de tráfico de comunicación entre los dos nodos de la capa de cliente, después de la eliminación. Una vez que se elimina el puerto, el sistema identifica un puerto de servidor de la capa de servidor que pierde la comunicación y, por lo tanto, mapea el puerto de cliente al puerto de servidor.

Lo siguiente puede usarse para eliminar un puerto de cliente y mapear un puerto de cliente a un puerto de servidor:

• Dada una lista de puertos de enrutador no mapeados y puertos ópticos no mapeados, elegir un puerto de enrutador X que sea parte del conjunto Y.

• Medir la cantidad de tráfico actual en el conjunto mediante observar los contadores de paquetes u octetos entrantes y salientes en el conjunto (por ejemplo, al consultar el enrutador mediante el uso del protocolo SNMP)

• Calcular si esta cantidad de tráfico aún puede transportarse por el conjunto en caso de que se elimine el enlace. Por ejemplo, si el conjunto tiene N enlaces, cada uno con una capacidad de Z Gb/s, y la cantidad de tráfico actual en el conjunto es Y Gb/s, entonces el enlace puede eliminarse si Y < U * (N-1) * Z, donde 0<U<1 representa la utilización máxima permitida en un conjunto según la política del operador.

• Eliminar el enlace del conjunto, al poner el puerto X en modo de mantenimiento, o al apagar su láser o reconfigurar el conjunto en los enrutadores en ambos extremos.

• Opcionalmente, comprobar que el puerto X ya no transporta tráfico mediante la observación de los contadores de paquetes u octetos entrantes y salientes en el puerto (por ejemplo, a través del protocolo SNMP)

• Apagar el láser en el puerto X

• Comprobar cuál de los puertos ópticos en el mismo sitio ya no ve la luz entrante. Esto puede hacerse mediante sondear todos los puertos y observar cuál de ellos tiene una indicación de que no recibe luz del cliente, y compararlo con su estado reciente (puede hacerse el mismo sondeo justo antes de apagar el láser de luz en el puerto X). Solo el puerto óptico M que se mapea a X debería experimentar un cambio de estado. Otra opción es suscribirse a las alarmas del mecanismo óptico y buscar una alarma de pérdida de luz (LOL) de un puerto óptico M.

• El sistema registrará en su base de datos que los puertos X y M se han mapeado.

• El puerto X se enciende y se pone en servicio, y se vuelve a incluir en el conjunto.

• El proceso se repite para todos los puertos restantes no mapeados.

Las Figuras 13-16 ilustran aún otro enfoque para mapear la conectividad entre capas o dominios de una red multicapa.

La Figura 13 ilustra una red que incluye los dominios 50 y 52. Cada dominio puede gestionarse por separado y los enlaces que conectan estos dominios pueden no gestionarse por completo. Por lo tanto, es importante descubrir automáticamente cómo se conectan estos enlaces. Un ejemplo de esto son los dos dominios ópticos 54 y 56 que se conectan mediante interfaces Ethernet 58 y 60, las cuales no soportan automáticamente el descubrimiento de la conectividad.

Para mapear los puertos de la capa de cliente y de servidor, el presente sistema utiliza parte o toda la información siguiente, que se recopila de la red multicapa:

(i) topología de red de cada capa - nodos y enlaces que interconectan los nodos en la capa;

(ii) conexiones de extremo a extremo en la capa de servidor;

(iii) mapas documentados de interconexiones entre los puertos laterales de línea de la capa de cliente y los puertos respectivos en la capa de servidor, en caso de que esta información exista de otra fuente - tal como una base de datos externa o protocolos de gestión de enlaces; y

(iv) estadísticas de tráfico en los puertos de entrada y salida de cada capa, tal como el recuento de paquetes o el recuento de bytes (octetos)

(v) alarmas sobre pérdida de conectividad (o pérdida de luz) en los puertos laterales de línea de la capa de cliente y los puertos respectivos en la capa de servidor.

Esta información se utiliza por la presente invención para identificar y verificar las interconexiones reales entre los puertos laterales de línea de la capa de cliente y los puertos respectivos en la capa de servidor, y generar un mapa de tales interconexiones.

La información anterior (i-v) que recopila el sistema de la presente invención puede obtenerse a través de varios protocolos de capa de red (tal como IGP o BGP-LS para topología y contadores de Netflow o Protocolo Simple de Administración de Redes[SNMP] para mediciones de tráfico, o NETCONF), sistemas de gestión (por ejemplo, SAM de Alcatel) o controladores centralizados para cada una de las capas (por ejemplo, WAE de Cisco o Northstar de Juniper), o herramientas de planificación (por ejemplo, el diseño MATE de Cisco), o herramientas de recopilación de datos de red (por ejemplo, el recopilador MATE).

El sistema recopila información para cada sitio que incluye los nodos de servidor y de cliente (62 y 64, y 66 y 68 respectivamente, Figura 14). El sistema puede también obtener alguna información sobre las interconexiones entre capas, por ejemplo, las interconexiones bidireccionales 72 y 74 (cada una de las cuales incluye dos enlaces unidireccionales).

El sistema comienza a recopilar contadores de tráfico y estadísticas para cada puerto de entrada y salida en la capa de servidor y la capa de cliente (por ejemplo, los puertos 76, 78 y 80, y 82 que se muestran en la Figura 14). Dichos contadores (que proporcionan el recuento de paquetes Ethernet o el recuento de bytes o una distribución del recuento de paquetes en función del tamaño del paquete) existen en las interfaces de la capa de paquetes del cliente tanto en los puertos de entrada 76 como en los puertos de salida 80. En la capa de servidor (por ejemplo, óptica), tales contadores existen en muchos de los puertos de entrada Ethernet 78/82, por ejemplo, en algunos de los transpondedores Cisco ONS 15454. Los contadores pueden existir o no en los puertos de salida del mecanismo de transporte, pero pueden derivarse con exactitud ya que el comportamiento del tráfico durante un período de tiempo dado en un puerto de entrada 78 de un primer servidor óptico 62 es idéntico en circunstancias normales (sin fallas) al comportamiento del tráfico durante el mismo período de tiempo en el puerto de salida 82 de un segundo servidor óptico 64, siempre que una conexión óptica 100 conecte estos dos puertos (Figura 15).

El sistema recopila estos contadores aproximadamente al mismo tiempo desde varios puertos de un sitio dado. Ya que los diferentes puertos normalmente transportarán diferentes cantidades de tráfico en diferentes puntos en el tiempo, es posible correlacionar el comportamiento del tráfico según lo medido por los contadores y deducir qué comportamientos del tráfico coinciden y probablemente representan los puertos conectados.

El comportamiento del tráfico se basa normalmente en el cambio en el tráfico (el delta) desde la última medición de los contadores. Los contadores también pueden basarse en el valor absoluto de los contadores, pero el algoritmo debe tener en cuenta el hecho de que un operador puede reiniciar algunos contadores. El comportamiento puede basarse en diferentes tipos de recuentos, tal como el recuento total de paquetes, el recuento total de bytes o una distribución del recuento de paquetes en función del tamaño del paquete - según se define en la base de información de gestión (MIB) del Monitoreo de Red Remota (RMON) estándar para SNMP. Puede lograrse una correlación más exacta mediante la combinación de diferentes tipos de contadores. El muestreo de contadores puede efectuarse periódicamente en todos los puertos para tener suficientes deltas para la comparación. En cualquier caso, el enfoque de mapeo debe ser lo suficientemente robusto como para proporcionar valores exactos y descartar inconsistencias temporales debido a fallas que pueden afectar el recuento de paquetes, o un reinicio manual. Tales enfoques pueden utilizar la información de recuento de paquetes para generar gráficos de recuentos de paquetes a lo largo del tiempo y para modelar el gráfico o identificar y comparar patrones de tráfico tal como tendencias, picos, puntos máximos locales y mínimos locales, aumento monótono o disminución monótona en el recuento de paquetes, etcétera. Los enfoques de modelado pueden basarse en encontrar una pendiente o curva polinomial que esté lo más cerca posible de los puntos medidos para un puerto dado (mediante el uso del enfoque de mínimos cuadrados) y encontrar polinomios para diferentes puertos que tengan coeficientes coincidentes. Tales enfoques se describen con mayor detalle en la presente descripción a continuación y en el Ejemplo 3 de la sección de Ejemplos que sigue.

En los casos donde las mediciones de tráfico a través de un enlace no permiten un algoritmo de mapeo robusto o los puertos interconectados no forman parte de un enlace de capa de cliente activo y, por lo tanto, los contadores no recopilan suficiente información para el mapeo, el sistema de la presente invención también puede usarse junto con el tráfico de control que se genera activamente.

Este enfoque también puede usarse como desempate, si una función de correlación no puede diferenciar entre varias opciones de conectividad cliente-servidor. Para generar tráfico activamente, el sistema hace que un enrutador envíe un ping repetitivo con paquetes grandes desde el puerto de enrutador de salida (76 en la Figura 15) a un puerto de enrutador de entrada remota 80 a través del enlace 100, el cual se enruta ópticamente a través de los nodos 62, 102, y 64. Por ejemplo, el comando 'ping - n1000 -160000' generará 1000 mensajes, cada uno de 60000 bytes de longitud. Este tráfico se reflejará en los contadores de un puerto, tanto en los enrutadores IP como en los servidores ópticos conectados.

Los contadores de tráfico también pueden usarse para descubrir interconexiones entre dominios, es decir, para el mapeo entre dominios. El proceso general es similar al descrito anteriormente, excepto que los contadores de tráfico se leen de las interfaces entre dominios, es decir, las interfaces de los enlaces 58 y 60 entre los nodos 54 y 56 en la Figura 13. Si se necesita la generación de mensajes de ping como se describe anteriormente, entonces el mapeo de múltiples dominios requerirá acceso a los enrutadores, lo que requiere soportes multicapas además de soportes de múltiples dominios. Si algunos enlaces ópticos entre dominios no forman parte de un enlace IP activo, el presente sistema puede crear un enlace IP temporal que usará el enlace óptico entre dominios inactivo, generará mensajes de ping en él y luego desactivará el enlace IP. Este enlace IP temporal no se agregará a la topología de red de la capa IP (IGP) y no se usará para el tráfico real.

La correlación de contadores de diferentes puertos puede efectuarse mediante el uso del siguiente enfoque. Con referencia al sistema de configuración de puertos N x N que se muestra en la Figura 16, el objetivo es encontrar un mapeo exacto entre cada uno de los N puertos en el lado izquierdo que se denotan por X^k (k=1,2,...,N) a los puertos del lado derecho que se denotan por Y^p (p=1,2,...,N).

Para cada puerto, la notación X^k[n] (k=1,2,...,K), significa los valores de la señal tal como se muestreó en el tiempo t[n], donde n=1,2,...,N. Y^p[n] se define de manera similar.

La señal X^k[n], Y^p[n] representan los contadores de paquetes, así como cualquier otro parámetro dependiente del tiempo. El algoritmo en este ejemplo incluye 4 etapas:

Etapa 1:

Calcular la derivada para cada una de las señales anteriores X^k[n] e Y^p[n]. Una derivada de un valor de la señal muestreada puede definirse como:

(Ecuación 1)

Donde p[n] es el contador de muestras y t[n] es el tiempo en el que se tomaron las muestras.

Se usa una derivada ya que los cambios de tráfico se producen en ráfagas y una derivada permite la detección de esos cambios.

Etapa 2:

Opcional (se basa en el nivel de ruido) - Suavizar los resultados mediante el uso de un filtro promedio móvil - del orden de 3 (por ejemplo):

Etapa 3:

Calcular la correlación cruzada entre cada par de señales/puertos, la correlación cruzada puede definirse mediante una de las siguientes fórmulas:

Donde R*[n] representa un valor de coincidencia conjugado en el caso de una señal compleja. Para una señal de valor real: R*[n] = R[n]

Por defecto, puede usarse la primera fórmula, sin embargo, en caso de ruido fuerte, la segunda fórmula puede usarse para mejorar los resultados.

Siguiendo esta etapa, se obtienen N señales de correlación cruzada para cada puerto en el lado izquierdo de la Figura 16, y en total: NxN=N2 señales/vectores.

Etapa 4:

Para cada puerto Xk (k=1,2,...,N) encontrar un puerto asociado Yp (p=1,2,...,N) calcular el valor máximo de la correlación cruzada y compararlo con un umbral predefinido.

La información de enlace que no depende de contadores de paquetes también puede usarse para el mapeo. Por ejemplo, el presente sistema puede reducir la potencia de transmisión en un extremo de un enlace entre capas y detectar el cambio en la potencia que se recibe en el otro extremo de este enlace. Siempre que el cambio de potencia sea pequeño, este es un evento no intrusivo.

La latencia del enlace puede detectarse tanto con el mecanismo óptico como con el mecanismo IP y también usarse para el mapeo. Por ejemplo, cuando la capa IP usa una comprobación de conectividad rápida y mensajes de verificación de conectividad (CC/CV - como se define en el estándar MPLS-TP), la latencia puede evaluarse con exactitud. Una vez que existe una evaluación de latencia tanto para las conexiones ópticas como para los enlaces IP, el sistema encontrará la coincidencia más cercana en la latencia para identificar cuál enlace IP coincide con cuál conexión óptica.

También puede usarse para el mapeo una correlación de fallas en ambas capas, que se basa lo mismo en información actual de fallas que en información de fallas históricas o en una combinación de ambas. El presente sistema busca indicaciones de fallas tales como alarmas o syslog que ocurrieron aproximadamente al mismo tiempo tanto en la capa óptica como en la capa IP. Cuando falla una conexión óptica, su soporte de enlace IP falla también y esto indica un posible mapeo entre los dos.

Como se usa en la presente descripción, el término "aproximadamente" se refiere a ± 10 %.

Objetivos, ventajas y características novedosas adicionales de la presente invención resultarán evidentes para un experto en la técnica tras el examen de los siguientes ejemplos, que no pretenden ser limitantes.

Ejemplos

Se hace referencia ahora a los siguientes ejemplos, los cuales, junto con las descripciones anteriores, ilustran la invención de una manera no limitante.

Ejemplo 1

Restauración de Red

La red que se ilustra en la Figura 10 incluye 4 enrutadores IP 11-14, 4 ROADM (enrutadores ópticos) 21-24, 4 puertos de enrutador de repuesto que se conectan a la capa óptica 41-44 y 6 enlaces ópticos 31-36.

La longitud de los enlaces ópticos 31-34 es de 10 km, mientras que el enlace 35 es de 50 km y la longitud del enlace 36 es de 40 km. Cuando falla el enlace 31, fallan los enlaces IP 51 y 52. La ruta óptica alternativa más corta para estos enlaces IP pasa a través de los enlaces ópticos 33, 32 y 34 (30 km). Sin embargo, esta ruta obligará a los enlaces IP 51 y 52 a compartir los enlaces ópticos con los enlaces IP 53-55, comprometiendo la red en caso de otra falla óptica. Un compromiso tal puede violar la política de la capa IP del proveedor de servicios. La ruta alternativa (33, 32, 34) es una elección probable para la restauración óptica pura, ya que la capa óptica no conoce de las necesidades de diversidad de la capa IP.

El presente sistema identificará la ruta a través de los enlaces ópticos 35 y 34 como la mejor alternativa, ya que los enlaces IP resultantes solo compartirán un enlace óptico con el enlace IP 55. Por lo tanto, el presente sistema configurará la capa óptica para restaurar las rutas ópticas que soportan los enlaces IP 51 y 52 para usar la ruta de restauración (35, 34). Si el operador también tiene una restricción de latencia para un enlace IP, que se traduce en una distancia máxima de 40 km, entonces el presente sistema preferirá una ruta alternativa de (33, 36) en su lugar. En el caso de que una falla desactive los enlaces ópticos 31 y 36. La restauración óptica intentará restaurar los enlaces IP 51 y 52 a través de la ruta óptica (33, 36), pero esta ruta estará desactivada. La falla de restauración será reportada al controlador actual, que luego forzará otras opciones: ruta (33, 32, 34) o ruta (35, 34). En dependencia de si el operador prioriza la diversidad sobre la latencia baja o viceversa, el controlador actual solicitará a la capa óptica que establezca rutas alternativas (35, 34) o (33, 32, 34) respectivamente.

Cuando falla el puerto de un enrutador - por ejemplo, el puerto del enrutador 11 que se conecta al enlace 51 - el presente sistema recibirá una alarma e identificará un puerto de reserva 41. Apagará el puerto fallido y copiará los datos de configuración de IP saliente (tales como la dirección IP, la métrica de enrutamiento y los datos del conjunto de enlaces) al puerto 41. Luego se solicitará a la capa óptica que vuelva a conectar el enlace de soporte de la ruta fallida 51 al puerto 41 en lugar de al puerto fallido. Una vez que el enlace esté activo, el tráfico comenzará a fluir y se restaurará la capacidad fallida.

Haciendo referencia nuevamente a la Figura 10, puede no estar claro si la trayectoria óptica que implementa el enlace IP 51 se conecta al 2do puerto desde la parte superior en los enrutadores 11 y 12 y el enlace IP 42 se conecta a los 3ras puertos en ambos enrutadores, o viceversa. Para mapear la conectividad, el presente sistema espera hasta que el nivel de tráfico entre los enrutadores 11 y 12 sea lo suficientemente bajo para que se soporte a través de un solo enlace. Sujeto a la política que define el operador (por ejemplo, "sólo realizar tales acciones en medio de la noche"), el actual controlador elimina el enlace 52 del conjunto de enlaces entre estos enrutadores. Luego, el controlador puede apagar el puerto IP en el enrutador 11 que se conecta al enlace 52. Como resultado, el puerto óptico que se conecta a este puerto emitirá una alarma por pérdida de luz que proporcionará una indicación de la interconectividad de los puertos. El presente controlador entonces instruirá al puerto óptico en el otro extremo de la ruta óptica para cerrar su puerto. Como resultado, el puerto IP en el enrutador 12 emitirá una alarma por pérdida de luz. Esto establecerá cómo se mapean los puertos en el extremo remoto. El proceso se repite en la otra dirección (del enrutador 12 al 11) para establecer el mapeo en la dirección inversa. Una vez finalizado el proceso, el enlace 52 se vuelve a poner en servicio y se agrega al conjunto de enlaces. El proceso de mapeo ahora puede continuar para descubrir otros enlaces (por ejemplo, el enlace 51). Descubrir cómo los puertos IP del enlace 53 se conectan a los puertos ópticos es más complicado, ya que eliminar un solo enlace afectará negativamente al tráfico. Por lo tanto, los puertos de repuesto 43 y 44 se usan para configurar un nuevo enlace temporal entre los enrutadores 13 y 14, una vez que está activo, se une con el enlace 53. Posteriormente, el enlace 53 se saca del conjunto- esto no afecta el tráfico, ya que ahora puede usar el enlace recién agregado. El proceso de apagar los puertos se repite aquí, después de lo cual el enlace 53 se vuelve a poner en servicio y los puertos de repuesto 43 y 44 se liberan nuevamente.

Ejemplo 2

Aplicación de métricas de ingeniería de tráfico (te) en la restauración de la red

Un enfoque de restauración descrito anteriormente en la presente descripción asume que la capa IP en la restauración no reenruta el tráfico que no es adecuado para la ruta de restauración recién establecida.

Para garantizar que los servicios con un requisito de baja latencia retengan la latencia requerida mientras la red usa rutas ópticas más largas al restaurar algunos enlaces IP, puede efectuarse la restauración del tráfico de la capa IP junto con la modificación de las métricas de ingeniería de tráfico (TE), tales como la latencia del enlace para la ruta de restauración. Esto asegura que, si la latencia de la ruta de restauración de un enlace IP es demasiado alta, los enrutadores se darán cuenta de este cambio y este enlace no se usará para tráfico sensible a la latencia. Puede usarse un enfoque similar para el costo de la ruta de restauración. Si el costo aumenta debido al enrutamiento a través de regeneradores, o debido a la mayor longitud de la ruta de restauración, entonces debe modificarse la métrica de enlace pertinente y el tráfico que puede evitar enlaces de alto costo lo hará.

En las Figuras 17-18c se ilustra un ejemplo del comportamiento del tráfico sensible a la latencia. La red que se muestra en estas figuras incluye enlaces ópticos de longitud similar 140 (fibra óptica) que conectan enrutadores de servidor 120 [multiplexor óptico reconfigurable de adición- supresión (ROADM)] y enlaces IP 130 que conectan enrutadores de cliente 110 a través de la ruta óptica. La configuración de red que se muestra en este ejemplo soporta un servicio que puede tolerar una latencia de hasta 4 enlaces ópticos.

Las Figuras 18a-c ilustran cómo un servicio de este tipo se enruta a través de esta red en condiciones normales en (Figura 18a), y su enrutamiento a través de la red después de la recuperación óptica de una falla (Figura 18b), asumiendo que toma la misma ruta de capa IP. Esto está bien para el tráfico no sensible a la latencia; sin embargo, si la latencia máxima es de 4 saltos, la capa IP debe enrutar el servicio a través de una ruta IP diferente (Figura 18c).

Ejemplo 3

Coincidencia de puertos a través del recuento de tráfico

Pueden usarse varios enfoques para hacer coincidir los puertos de cliente y de servidor en base a los recuentos de tráfico a través de estos puertos. Se selecciona un grupo de N puertos de cliente y de servidor y se recogen muestras de estos puertos a intervalos fijos. Pueden usarse dos tipos de contadores de tráfico:

(i) Contadores del número de paquetes en el puerto; y/o

(ii) Contadores del número de bytes (octetos) en el puerto.

Las muestras recolectadas se procesan previamente para verificar que existe una cantidad suficiente de muestras para el algoritmo. Los vacíos que se provocan por la falta de muestras se rellenan, por ejemplo, mediante interpolación. Los períodos de muestreo con valores de muestras decrecientes provocados, por ejemplo, por el reinicio manual de los contadores, se ignoran y los contadores de bytes para equipos que no cuentan algunos de los encabezados de paquetes se ajustan en consecuencia. A continuación, se calcula un "valor de coincidencia" que representa la probabilidad de una coincidencia entre cada par de puertos de acuerdo con uno de los siguientes enfoques:

(i) estimación de la pendiente, en base a la tendencia global de las muestras;

(ii) ajuste del modelo, en base a la tendencia global de las muestras; y

(iii) detección de patrones, en base a fenómenos locales en el gráfico (por ejemplo, ráfaga de la actividad del contador que se detecta como un pico en el gráfico).

Las muestras procesadas de pares de puertos de cliente y de servidor se comparan para encontrar una coincidencia. La comparación puede ser absoluta, por ejemplo, el valor de coincidencia de cada par de puertos se compara con un umbral absoluto fijo o relativo, por ejemplo, el valor de coincidencia para diferentes pares de puertos se compara y el mejor ajuste entre todos los pares se identifica como una coincidencia probable.

(i) Estimación de pendiente

La Figura 19 es un gráfico que ilustra la estimación de pendiente para tres puertos: puerto X, puerto Y y puerto Z. Las muestras que se toman de un puerto se grafican con el eje x que representa el tiempo en que se tomó la muestra y el eje y representa el valor absoluto del contador (recuento de paquetes o recuento de bytes). Luego se determina una línea recta más cercana a las muestras de cada puerto y se calcula su pendiente. Las pendientes de las líneas que representan diferentes puertos se comparan para identificar pares coincidentes.

Como puede observarse en la Figura 19, la línea recta que pasa más cerca de las muestras del puerto óptico X y la línea recta que pasa más cerca de las muestras del puerto IP Y tienen una pendiente similar, por lo que puede determinarse que el puerto óptico X y el puerto IP Y son un par coincidente. Además, puede determinarse que la pendiente asociada con la línea recta que pasa más cerca de las muestras del puerto óptico Z es diferente de la pendiente asociada con el puerto óptico X y de la pendiente asociada con el puerto Y, por lo que se determina que el puerto óptico X y el puerto IP Z no son un par coincidente y, de manera similar, el puerto IP Y y el puerto óptico Z no son un par coincidente.

(ii) Ajuste del modelo

La Figura 20 es un gráfico que ilustra el ajuste del modelo. Las muestras de tráfico que se toman de un puerto se grafican con el eje x que representa el tiempo en que se tomó la muestra y el eje y representa el valor absoluto del contador (recuento de paquetes o recuento de bytes). A continuación, se identifica un polinomio de grado N más cercano a las muestras de cada puerto, por ejemplo, mediante el uso del ajuste del modelo como se describe anteriormente, y este polinomio representa un modelo para el puerto. La similitud entre los modelos que representan un par de puertos se cuantifica, por ejemplo, calculando la diferencia promedio entre los valores de y para los dos modelos en una pluralidad de puntos a lo largo del eje x. Este valor de diferencia se usa para determinar una coincidencia entre un par de puertos; cuanto menor sea el valor de la diferencia, es más probable que coincida el par de puertos. El gráfico de la Figura 20 muestra tres líneas polinómicas que representan tres puertos. La línea superior que representa el puerto óptico Z se distancia de las dos líneas que representan el puerto óptico X y el puerto IP Y. El cálculo del valor de diferencia para el puerto óptico X y el puerto IP Y puede proporcionar un valor bajo, lo que indica que estos modelos polinomiales un par coincidente.

(iii) Detección de patrones

La Figura 21 ilustra la detección de patrones (o ráfagas). Las muestras que se toman de un puerto se grafican con el eje x que representa el tiempo en que se tomó la muestra y el eje y representa la diferencia en el valor del contador de una medición anterior (recuento de paquetes o recuento de bytes). La ubicación de las ráfagas en el recuento de paquetes o bytes a lo largo del tiempo se identifica (como picos en el gráfico) para cada gráfico de muestras de puerto y, opcionalmente, se aplica un filtro de paso bajo (suavizando la curva) para tener en cuenta las ráfagas que se desplazan en el tiempo debido a limitaciones de medición.

Los patrones de ráfagas se correlacionan para cada par de puertos y se identifica una coincidencia si el valor de correlación que indica un grado de correlación es suficientemente alto (por ejemplo, por encima de un umbral predeterminado). Puede usarse una función de autocorrelación para determinar el valor de correlación entre cada par de puertos, por ejemplo, al calcular una correlación cruzada entre cada par de señales/puertos mediante el uso de las ecuaciones 3 y 4 anteriores.

En la Figura 21, el recuento de tráfico de tres puertos se indica en el gráfico. Las ráfagas de tráfico para cada puerto se conectan mediante una línea en el gráfico y las líneas se verifican para determinar la correlación entre cada par. Como puede verse en el gráfico, las líneas del puerto óptico X y el puerto IP Y están muy cerca y, por lo tanto, están altamente correlacionadas. La línea que conecta las ráfagas de tráfico para el puerto óptico Z se distancia de las líneas que conectan las ráfagas de tráfico de los puertos X e Y, y existe una baja correlación entre el puerto óptico X y el puerto IP Z, así como entre el puerto IP Y y el puerto óptico Z.

Ejemplos adicionales de patrones que pueden identificarse y compararse mediante el sistema de la presente invención incluyen tendencias ascendentes o descendentes en la actividad del tráfico y combinaciones de las mismas que incluyen dientes de sierra y patrones de tendencias crecientes/decrecientes (ascendentes/descendentes) repetidos en el gráfico.

En el contexto de algunas modalidades de la presente descripción, a modo de ejemplo y sin limitación, términos tales como 'operar' o 'ejecutar' implican también capacidades, tales como 'operable' o 'ejecutable', respectivamente.

Los términos 'procesador' o 'computadora', o sistema de los mismos, se usan en la presente descripción como contexto ordinario de la técnica, tal como un procesador de propósito general o un microprocesador, procesador RISC o DSP, que posiblemente comprenda elementos adicionales como memoria o puertos de comunicación. Opcional o adicionalmente, los términos 'procesador' o 'computadora' o sus derivados denotan un aparato que es capaz de llevar a cabo un programa que se proporciona o se incorpora y/o es capaz de controlar y/o acceder a aparatos de almacenamiento de datos y/u otros aparatos, tales como puertos de entrada y salida. Los términos 'procesador' o 'computadora' también denotan una pluralidad de procesadores o computadoras que se conectan y/o se enlazan y/o se comunican de otra manera, posiblemente compartiendo uno o más recursos tales como una memoria.

Los términos 'software', 'programa', 'procedimiento de software' o 'procedimiento' o 'código de software' o 'código' o 'aplicación' pueden usarse indistintamente de acuerdo con el contexto de los mismos, y denotan una o más instrucciones o directivas o circuitos para realizar una secuencia de operaciones que generalmente representan un algoritmo y/u otro proceso o método. El programa se almacena en o sobre un medio legible por ordenador no transitorio que tiene las instrucciones del software almacenadas en él. El medio legible por ordenador puede ser, por ejemplo, RAM, ROM o disco, o puede incorporarse en un circuito accesible y ejecutable operativamente mediante un aparato tal como un procesador u otros circuitos.

El procesador y el programa pueden constituir el mismo aparato, al menos parcialmente, tal como una matriz de puertas electrónicas, tales como FPGA o ASIC, que se diseñan para realizar una secuencia programada de operaciones, que opcionalmente comprenden o se enlazan con un procesador u otros circuitos.

El término aparato computarizado o un sistema computarizado o un término similar denota un aparato que comprende uno o más procesadores operables o que funcionan de acuerdo con uno o más programas.

Como se usa en la presente descripción, sin limitación, un módulo representa una parte de un sistema, tal como una parte de un programa que opera o interactúa con una o más partes en la misma unidad o en una unidad diferente, o un componente o ensamble electrónico para interactuar con uno o más de otros componentes. Como se usa en la presente descripción, sin limitación, un proceso representa una colección de operaciones para lograr un determinado objetivo o resultado.

Como se usa en la presente descripción, el término 'servidor' denota un aparato computarizado que proporciona datos y/o servicio o servicios operativos a uno o más de otros aparatos. Los términos 'configurar' y/o 'adaptar' y/o 'determinar' y/o 'calcular' para un objetivo, o una variación del mismo, implican usar al menos un software y/o circuito electrónico y/o aparato auxiliar que se diseña y/o implementa y/u opera u es operativo para lograr el objetivo.

Un dispositivo que almacena y/o comprende un programa y/o datos constituye un artículo de fabricación. A menos que se especifique lo contrario, el programa y/o los datos se almacenan en un medio no transitorio.

El diagrama de flujo y los diagramas de bloques ilustran la arquitectura, la funcionalidad o el funcionamiento de posibles implementaciones de sistemas, métodos y productos de programas informáticos de acuerdo con diferentes modalidades del presente tema descrito. A este respecto, cada bloque en el diagrama de flujo o los diagramas de bloques puede representar un módulo, segmento o porción del código de programa, que comprende una o más instrucciones ejecutables para implementar la función o funciones lógicas especificadas. También debe tenerse en cuenta que, en algunas implementaciones alternativas, las operaciones ilustradas o descritas pueden ocurrir en un orden diferente o en combinación o como operaciones concurrentes en lugar de operaciones secuenciales para lograr el mismo efecto.

Se aprecia que ciertas características de la invención, que, para mayor claridad, se describen en el contexto de modalidades separadas, también pueden proporcionarse en combinación en una única modalidad. A la inversa, diferentes características de la invención, que se describen, por brevedad, en el contexto de una única modalidad, también pueden proporcionarse por separado o en cualquier subcombinación adecuada.

Aunque la invención se ha descrito junto con modalidades específicas de la misma, es evidente que muchas alternativas, modificaciones y variaciones serán evidentes para los expertos en la técnica, en la medida en que caigan dentro del alcance de las reivindicaciones adjuntas. Por consiguiente, se pretende abarcar todas estas alternativas, modificaciones y variaciones que caen dentro del alcance de las reivindicaciones adjuntas.

Claims (8)

1. REIVINDICACIONES

   i. Un sistema para mapear una red de comunicación multicapa que tiene una capa óptica y una capa de protocolo de Internet (IP), el sistema que comprende un controlador que se configura para ejecutar instrucciones para: recibir datos de tráfico de un primer contador de tráfico que se ubica en un puerto de la capa óptica y un segundo contador de tráfico que se ubica en un puerto de la capa IP;

   calcular un patrón de tráfico en el puerto de la capa óptica y un patrón de tráfico en el puerto de la capa IP a partir de los datos de tráfico que se reciben;

   comparar el patrón de tráfico en el puerto de la capa óptica con el patrón de tráfico del puerto de la capa IP; calcular un valor de coincidencia a partir de los patrones de tráfico comparados que representa la probabilidad de una coincidencia entre el puerto de la capa óptica y el puerto de la capa IP representativo de los puertos conectados; y

   determinar que el puerto de la capa óptica y el puerto de la capa IP se conectan al comparar el valor de coincidencia con un umbral fijo.
2. 2. El sistema de la reivindicación 1, en donde dichos patrones de tráfico son los recuentos de tráfico de dichos primer y segundo contador durante un período de tiempo.
3. 3. El sistema de la reivindicación 1, en donde dicha comparación es identificar un pico similar en dichos patrones de tráfico de dichos puertos.
4. 4. El sistema de la reivindicación 1, en donde dichos patrones de tráfico son pendientes de recuentos de datos de tráfico durante un período de tiempo, y en donde dichas pendientes son pendientes de líneas que se obtienen mediante el uso de un algoritmo de mínimos cuadrados, las líneas que tienen una suma mínima de distancias a partir de recuentos de datos de tráfico durante dicho período de tiempo.
5. 5. El sistema de la reivindicación 1, en donde dicho controlador se configura para ejecutar instrucciones para identificar puertos IP de un solo conjunto de enlaces que se enrutan a través de la misma ruta de la capa óptica y usar dichos puertos IP de manera intercambiable para reenrutar el tráfico.
6. 6. Un sistema para mapear una red de comunicación multicapa que tiene una capa óptica y una capa de protocolo de Internet (IP), el sistema que comprende un controlador que se configura para ejecutar instrucciones para: recibir datos de tráfico de un primer contador de tráfico que se ubica en un puerto de la capa óptica y de un segundo contador de tráfico que se ubica en un puerto de la capa IP;

   calcular una función de correlación cruzada entre los valores de la señal del primer contador y los respectivos valores de la señal del segundo contador medidos en tiempos correspondientes; y

   determinar que el puerto de la capa óptica y el puerto de la capa IP se conectan al comparar un valor máximo de la función de correlación cruzada calculada con un umbral predefinido.
7. 7. El sistema de la reivindicación 6, en donde los vacíos en los datos de tráfico que se provocan por la falta de muestras de tráfico que se recogen en los puertos se llenan mediante interpolación.
8. 8. Un sistema para mapear una red de comunicación multicapa que tiene un primer dominio y un segundo dominio de una capa óptica, el sistema que comprende un controlador que se configura para ejecutar instrucciones para:

   recibir datos de tráfico de un primer contador de tráfico que se ubica en un puerto del primer dominio de la capa óptica y un segundo contador de tráfico que se ubica en un puerto del segundo dominio de la capa óptica calcular un patrón de tráfico en el puerto del primer dominio y un patrón de tráfico en el puerto del segundo dominio a partir de los datos de tráfico que se reciben

   comparar el patrón de tráfico en el puerto del primer dominio con el patrón de tráfico del puerto del segundo dominio;

   calcular un valor de coincidencia a partir de los patrones de tráfico comparados que representa una probabilidad de una coincidencia entre el puerto en el primer dominio y el puerto en el segundo dominio representativo de los puertos conectados; y

   determinar que el puerto del primer dominio y el puerto del segundo dominio se conectan al comparar el valor de coincidencia con un umbral fijo.