ES2381748T3

ES2381748T3 - Método y equipo para la recuperación de fallos en un anillo óptico de ráfagas adaptable y un método de gestión de fallos

Info

Publication number: ES2381748T3
Application number: ES06817964T
Authority: ES
Inventors: Guiling Wu; Jianping Chen; Xinwan Li; Wenjun Qian; Yue Liu
Original assignee: Huawei Technologies Co Ltd; Shanghai Jiaotong University
Current assignee: Huawei Technologies Co Ltd; Shanghai Jiaotong University
Priority date: 2006-03-24
Filing date: 2006-12-07
Publication date: 2012-05-31
Anticipated expiration: 2026-12-07
Also published as: EP1998503A1; ATE546919T1; WO2007109937A1; EP1998503B1; CN101043267B; EP1998503A4; CN101043267A

Abstract

Un método para gestionar el fallo de un Anillo Óptico de Ráfagas Adaptable, ROBR, que comprende: aplicar un mecanismo steering (dirección) cuando falla un canal de control; y aplicar, cuando falla un canal de datos, un mecanismo para dejar de utilizar el canal de datos que falla y continuar utilizando los canales de datos que funcionan correctamente.

Description

Método y equipo para la recuperación de fallos en un anillo óptico de ráfagas adaptable y un método de gestión de fallos.

Campo de la invención

5 La presente invención está relacionada con el campo de las comunicaciones ópticas y, en particular, con un método y un equipo para la recuperación de fallos de un Anillo Óptico de Ráfagas Adaptable (ROBR) y un método de gestión de fallos.

Antecedentes

La Conmutación Óptica de Ráfagas (OBS) es un modelo de red óptica atractivo orientado a la Multiplexación por

10 División de Longitud de Onda Densa (DWDM) de servicios IP de elevada velocidad y elevado índice de ráfagas, y en los últimos años se ha convertido en un tema de actualidad en la investigación dentro del campo de las redes ópticas. En la OBS, un nodo extremo encapsula los datos de usuario en un Paquete de Datos de Ráfaga (BDP) y genera el correspondiente Paquete de Control de Ráfaga (BCP). El BCP tiene prioridad de transmisión sobre el BDP en el canal de control dedicado, y en los nodos intermedios se reserva el canal exclusivamente óptico para el BDP

15 correspondiente. El BDP se transmite directamente en el canal exclusivamente óptico preconfigurado después de ser retardado un período en el nodo extremo. Dicho modelo de reserva unidireccional sin la necesidad de confirmación reduce el tiempo de espera de retardo requerido para configurar un canal, y mejora la tasa de utilización del ancho de banda; el BDP de una granularidad media reduce la sobrecarga y mejora la tasa de utilización. La separación del BDP respecto al BCP, una granularidad apropiada y un modo de conmutación sin

20 ranuras de tiempo reducen los requisitos de los componentes ópticos y la complejidad de los nodos de conmutación intermedios, y hacen uso completo de las ventajas de las tecnologías ópticas y las tecnologías electrónicas actuales.

Una red óptica de ráfagas en anillo, caracterizada por una estructura simple y una recuperación automática protectora, no necesita una matriz de conmutación rápida a gran escala, y puede gestionar la estructura de red óptica popularizada en la actualidad para proteger las inversiones realizadas. Por lo tanto, la red de conmutación

25 óptica de ráfagas en anillo basada en una topología de anillo es de importancia práctica.

En los últimos años, se considera la red óptica de ráfagas en anillo como un modo de conmutación ideal de la Internet de próxima generación exclusivamente óptica, y acapara más y más atención.

La Figura 1 muestra la estructura de un Anillo Óptico de Ráfagas Adaptable (ROBR) en la técnica anterior.

Un ROBR es una red de conmutación óptica de ráfagas en anillo que integra un Anillo de Paquetes Adaptable (RPR)

30 y un OBS. El ROBR tiene una estructura de anillo dual inverso como el RPR. Con la integración de las características de OBS en el protocolo de control RPR estandarizado, el ROBR implementa gestión de tiempo de retardo, protección y restauración, y asignación de ancho de banda dinámico equitativo de los anillos ópticos de ráfagas. Más aún, el BDP se transmite en modo exclusivamente óptico, y es transparente al formato y velocidad del paquete de datos. El ROBR se caracteriza por: comparado con el RPR, el ROBR reserva recursos de canal de

35 forma unidireccional y es específico de un grupo de canales de datos y un grupo de canales de control, respectivamente; comparado con el OBS, el ROBR adopta una estructura de red en anillo y un modo de control basado en el anillo de paquetes adaptable.

La Figura 1 muestra la estructura de una red de ROBR. Un ROBR es una estructura de anillo doble inverso. El anillo externo se conoce generalmente como anillo 1, y el anillo interno se conoce generalmente como anillo 0. Cada anillo 40 tiene N+1 canales de longitud de onda, incluyendo un canal de control y N canales de datos. El canal de control se utiliza para transmitir los BCPs, mientras que los canales de datos se utilizan para transmitir los BDPs. El nodo del ROBR encapsula en un BDP los paquetes de datos que vienen de la subred local y que deberán pasar a través de la red ROBR, y envía el BDP a un anillo (determinado por el modo de selección de anillo) mediante conmutación de ráfagas. Los paquetes de datos dirigidos a la subred local se desvían a la subred correspondiente. Más aún, el nodo

45 del ROBR transfiere o procesa el BCP y el BDP correspondiente en función de la información recibida en el BCP procedente del canal de control. El BDP destinado al nodo local se devuelve al paquete de datos original (como por ejemplo un paquete IP) y, a continuación, se desvía a la subred correspondiente. La Tabla 1 es una comparación de las características de una red RPR con una red ROBR.

Tabla 1 Comparación entre las características de una red RPR y una red ROBR La comparación anterior indica que el ROBR se diferencia del RPR en que:

Condiciones de red correspondientes protección y restauración de RPR: a la Óptica/eléctrica/óptica, punto a punto, cabecera del paquete unida al paquete de datos, anillo bidireccional de dos fibras

Condiciones de red correspondientes protección y restauración de ROBR: a la Combinación óptica-eléctrica (óptica/eléctrica/óptica para el BCP, exclusivamente óptica para el BDP), cabecera BCP separada del BDP, anillo bidireccional de dos fibras

1.: En el ROBR, la cabecera BCP está separada del BDP en términos de tiempo y longitud de onda; y

2.: El canal de datos del ROBR es exclusivamente óptico y no es punto a punto.

La protección y la restauración es una de las claves para la implementación de redes operables. Sin embargo, hasta

5 ahora, no se ha presentado ninguna investigación sobre la protección y restauración de redes ópticas de ráfagas en anillo. En otras palabras, la técnica anterior no proporciona protección ni restauración de redes ópticas de ráfagas en anillo.

A continuación se describe el modelo de recuperación de fallos RPR con referencia a la Tabla 2, Figura 2 y Figura 3.

La Figura 2 muestra el mecanismo steering (dirección) del RPR en la técnica anterior, la Figura 3 muestra el

10 mecanismo wrapping (cambio de dirección) del RPR en la técnica anterior, y la Figura 4 muestra el mecanismo passthrough (traspaso) del RPR en la técnica anterior.

Tabla 2 tipos de protección y detección del RPR

Tipo de fallo: Detección y localización del fallo

Nodo: Fallo software Comprobación de consistencia

Fallo hardware: la función de reenvío sigue funcionando: Monitorización de pulsos

Fallo hardware: la función de reenvío no funciona, por ejemplo, falla la fuente de alimentación o está desenchufada la tarjeta: Autocomprobación

Fallo del enlace: Fallo del transmisor óptico Alarma de potencia óptica o del circuito de control: Signal_Failure (Fallo de la Señal) o Signal_Degrade (Degradación de la Señal)

Falo del receptor óptico: Alarma de potencia óptica, Relación Señal Ruido Ópticos (OSNR), y circuito de detección: Signal_Failure o Signal_Degrade

Corte en la fibra: Detección de la potencia óptica: Signal_Failure

Error de conexión del cable óptico (conexión incorrecta de los cables): Error de conexión del cable óptico: Signal_Failure

Gestión: Conmutación forzada Notificación de orden de gestión a la MAC: Forced_Switch (Conmutación forzada)

Conmutación manual: Notificación de orden de gestión a la MAC: Manual_Switch (Conmutación manual)

El RPR dispone de tres mecanismos de gestión de fallos:

15 Mecanismo steering: cuando ocurre un fallo, cada nodo (desde S1 a S7) conmuta los datos bajo protección a otro anillo en dirección al destino. Todos los nodos deben soportar este mecanismo. (Ver Figura 2)

Mecanismo wrapping: cuando ocurre un fallo, el nodo próximo al nodo que ha fallado cambia el servicio al anillo inverso. Este mecanismo es opcional. (Ver Figura 3)

Mecanismo passthrough: cuando dentro de un nodo ocurre un fallo software/hardware que no afecta a la función de 20 desvío, el nodo se convierte en un repetidor para desviar todos los paquetes. Este modo es opcional. (Ver Figura 4)

Mediante la comparación anterior, el RPR se diferencia del ROBR en algunas características. En concreto, en el RPR se combina una cabecera de paquete con el paquete de datos, mientras que en el ROBR el canal de datos está separado del canal de control, lo que implica que en el ROBR no se pueda aplicar la gestión de fallos y el mecanismo de recuperación de fallos en su conjunto del RPR.

25 La solicitud de patente internacional WO 2006030435 A2 divulga un mecanismo de protección eficiente para redes de conmutación mediante etiquetas basadas en anillo, como por ejemplo redes de conmutación multiprotocolo mediante etiquetas (MPLS). Los mecanismos de protección se diseñan para proteger rutas de conmutación puntomultipunto mediante etiquetas (LSPs).

La solicitud de patente internacional WO 2005062578 A2 divulga un método y un sistema para el encaminamiento

30 de datos de alta velocidad hacia y desde SANS (Redes de Área de Almacenamiento y Redes de Área de Servidor) mediante redes de conmutación óptica de ráfagas (OBS). Los componentes de redes de OBS, incluyendo los nodos extremos y los nodos de conmutación, se emparejan entre islas SAN.

Las solicitud de patente de los Estados Unidos US 2004234263 A1 divulga una red óptica, que incluye nodos extremos y de conmutación, que comunica, ópticamente, información formateada en ráfagas que se incluyen en una

: o más tramas de las unidades de transporte del canal óptico (OTU), basadas en la recomendación G.709 de la ITU-

T.

La solicitud de patente europea EP 1411666 A2 divulga una red óptica de dos fibras en anillo que tiene una pluralidad de nodos enlazados mediante un primer y un segundo enlace de fibra óptica, donde cada nodo comprende una primera sección de separación para separar las señales ópticas de las señales ópticas que circulan a través de la primera fibra en los canales de protección; una primera sección de adición/extracción para realizar la adición y/o extracción de señales ópticas que circulan a través de la primera sección de separación a una pluralidad de canales; una primera sección de conmutación para combinar las señales ópticas de los canales de protección con la primera fibra cuando no existe ningún fallo de enlace entre nodos adyacentes y para combinar señales ópticas en los canales de protección de la segunda fibra cuando existe un fallo de enlace entre nodos adyacentes; y una sección de control para identificar si ocurre, o no, un fallo del enlace óptico en las fibras y para generar una señal de control para activar un proceso de restauración en función del resultado identificado.

La solicitud de patente de los Estados Unidos US 2004057375 A1 divulga una red de topología en anillo, un número de enlaces de transmisión de interconexión de nodos para formar un primer y un segundo anillo operativos y un primer y un segundo anillo de protección óptica en una topología en anillo. Se establecen múltiples rutas operativas en cada anillo operativo y se establecen múltiples rutas de protección en cada anillo de protección correspondientes a las rutas operativas.

La solicitud de patente de los Estados Unidos US 2003206521 A1 divulga un método que consiste en la aplicación coordinada de nuevas formas de formatear y ensamblar ráfagas, encaminarlas, reservar/liberar ancho de banda, y, además, proporcionar recuperación de fallos y resolución de contiendas entre tipos de prioridad de paquetes y ráfagas con redes Conmutadas Ópticas de Ráfagas, Conmutadas Ópticas de Ráfagas mediante Etiquetas, Conmutadas Analógicas de Ráfagas mediante Etiquetas, y otras redes conmutadas de ráfagas sin almacenamiento intermedio.

La solicitud de patente de los Estados Unidos US 2003067919 A1 divulga una arquitectura de red integrada denominada Conmutación Analógica de Ráfagas mediante Etiquetas (LABS) utilizando MPLS mejorado/extendidocomo plano de control y se propone, para los nodos intermedios, la Conmutación Óptica de Ráfagas extendida como paradigma de conmutación que evita la necesidad de memoria de almacenamiento intermedio u otros dispositivos que retrasan los datos.

La solicitud de patente de los Estados Unidos US 2002118414 A1 divulga un método de configuración de rutas ópticas que fija una ruta óptica bidireccional normal sobre la mima ruta entre dos nodos, y fija una ruta óptica bidireccional de reserva sobre una ruta inversa de la ruta óptica normal. Se aumenta la eficiencia de ajuste de la ruta óptica mediante la compartición de una ruta óptica de reserva entre una pluralidad de rutas ópticas normales que tienen distintas rutas.

La solicitud de patente europea EP 1126649 A2 divulga un nodo local para su utilización en un anillo de red óptica síncrona. El nodo local incluye un conjunto de líneas de transmisión operativas y una línea de protección para conectar con un nodo remoto, una unidad de control para monitorizar las líneas de transmisión operativas y, tras la detección de una degradación de la transmisión de datos sobre una línea de transmisión operativa en concreto, se invoca un evento de conmutación con protección que provoca un reencaminamiento de las señales ópticas desde la línea de transmisión operativa específica a la línea de protección.

Resumen

La presente invención proporciona un método y un equipo para recuperación de fallos de un Anillo Óptico de Ráfagas Adaptable (ROBR) y un método de gestión de fallos, que pretenden ser aplicables al ROBR, caracterizado por la separación de los canales de control de los canales de datos.

En un modo de realización de la presente invención se proporciona un método de gestión de fallos del ROBR que incluye: cuando falla un canal de control, se aplica el mecanismo steering; cuando falla uno o más canales de datos, se dejan de utilizar los canales de datos que fallan; para el resto de canales de datos en funcionamiento normal, seguir utilizando los canales de datos en funcionamiento normal.

En un modo de realización de la presente invención se proporciona un equipo de recuperación de fallos de un AnilloÓptico de Ráfagas Adaptable, ROBR, que incluye:

un módulo (30) de protección de conmutación, adaptado para llevar a cabo el mecanismo steering cuando falla un canal de control; y, cuando falla un canal de datos, llevar a cabo un mecanismo para dejar de utilizar el canal de datos que ha fallado y continuar utilizando el resto de canales de datos en funcionamiento normal.

Como se puede observar en la solución técnica anterior, en un modo de realización de la presente invención, los fallos en la red ROBR se gestionan de forma efectiva sin retrasar la transmisión de paquetes utilizando este método de gestión de fallos: cuando falla un canal de control, aplicar el mecanismo steering; cuando falla uno o más canales de datos, dejar de utilizar los canales de datos que fallan; para el resto de canales de datos en funcionamiento normal, seguir utilizando los canales de datos en funcionamiento normal.

Breve descripción de los dibujos

La Figura 1 muestra la estructura de un ROBR. La Figura 2 muestra el mecanismo steering de un RPR. La Figura 3 muestra el mecanismo wrapping de un RPR. La Figura 4 muestra el mecanismo passthrough de un RPR. La Figura 5 es un diagrama de flujo de un método para la recuperación de fallos de un ROBR de acuerdo con un

primer modo de realización de la presente invención.

La Figura 6 muestra la estructura de un equipo para la recuperación de fallos de un ROBR en un modo de realización de la presente invención. La Figura 7 muestra el diagrama de flujo de un método para la recuperación de fallos de un ROBR de acuerdo con

un segundo modo de realización de la presente invención. La Figura 8 muestra la arquitectura lógica de un nodo ROBR en un modo de realización de la presente invención. La Figura 9 es un diagrama de flujo del método de gestión de fallos en un modo de realización de la presente

invención. Las Figuras 10A a 10F muestran diferentes estados de la gestión de fallos de un ROBR en el modo de realización que se muestra en la Figura 9.

Descripción detallada

A continuación se describe la presente invención en detalle con referencia a dibujos adjuntos y modos de realización preferidos.

La Figura 5 muestra un diagrama de flujo del método para la recuperación de fallos de un ROBR de acuerdo con el primer modo de realización de la presente invención; y la Figura 6, muestra la estructura de un equipo para la recuperación de fallos de un ROBR de acuerdo con un modo de realización de la presente invención.

Los principios para conseguir los objetivos anteriores son: primero, configurar un modelo de fallo de un ROBR y el método correspondiente de detección del fallo; y, a continuación, especificar una señal de alarma del fallo para enviarla a la capa MAC considerando cada tipo de fallo; y, por último, especificar el método de conmutación con protección de la capa MAC en distintas condiciones de fallo.

En concreto, como se muestra en la Figura 5, el método para la recuperación de fallos bajo la presente invención incluye los pasos que se describen a continuación.

Paso S102: configurar un modelo de fallos en función de las características del ROBR, en el que dicho modelo de fallos cubre diferentes tipos de fallo que se corresponden con las características.

Paso S104: enviar a la capa MAC una señal de alarma de fallo en función de cada tipo de fallo.

Paso S106: la capa MAC ejecuta un método de conmutación con protección en función de la señal de alarma del fallo.

Específicamente, como se muestra en la Figura 6, el equipo 100 para la recuperación de fallos bajo la presente invención incluye:

un módulo 10 de modelado, adaptado para fijar un modelo de fallos en función de las características del ROBR, en el que dicho modelo de fallos cubre distintos tipos de fallo que se corresponden con las características;

un modelo 20 de generación de señal, adaptado para enviar a la capa MAC una señal de alarma de fallo apropiada en función del tipo de fallo; un modelo 20 de generación de señal incluye, además, un submódulo de monitorización del enlace, adaptado para determinar el tipo de fallo mediante la detección y localización del fallo, en el que la detección del fallo se realiza en un modo en el que se separan los canales de datos de los canales de control; y

un módulo 30 de conmutación con protección, adaptado para permitir a la capa MAC que ejecute el método de conmutación con protección en función de la alarma del fallo. Un módulo de conmutación con protección incluye: un primer submódulo de proceso, adaptado para ejecutar el mecanismo steering con ajuste del tiempo de retardo cuando la señal de alarma se corresponde con un fallo del canal de control, y un segundo submódulo de proceso, adaptado para dejara de utilizar el canal de datos que falla cuando la señal de alarma se corresponde con un fallo del canal de datos, y para continuar utilizando el resto de canales de datos en funcionamiento normal.

El primer submódulo de proceso incluye, además: una unidad de difusión, adaptada para provocar que el segundo nodo que detecte un fallo difunda una notificación de fallo; una unidad de configuración del tiempo de retardo, adaptada para provocar que el primer modo que detecta y/o recibe una notificación de fallo localmente desvíe hacia el anillo dirigido al nodo de destino el servicio que se origina en el nodo actual y que pasa a través del segundo nodo, y ajustar el tiempo de retardo; y una unidad de descarte, adaptada para descartar el servicio que atraviesa el primer nodo y necesita ser protegido.

El segundo submódulo de proceso incluye: (i) una primera unidad de bloqueo, adaptada para provocar que el primer nodo deje de utilizar el canal de datos correspondiente cuando se localiza el fallo en el puerto de salida del primer nodo que detecta el fallo, y para provocar que el primer nodo envíe una notificación de fallo al nodo anterior contiguo a través de un canal de control del anillo inverso si el primer nodo no soporta conversión de longitud de onda; (ii) una segunda unidad de bloqueo, adaptada para provocar que el primer nodo envíe una notificación de fallo a través de un canal de control del anillo inverso cuando el fallo se localiza en el puerto de entrada del primer nodo; (iii) una tercera unidad de bloqueo, adaptada para provocar que el nodo anterior que recibe la notificación del fallo del canal de datos desactive el canal de datos correspondiente; y (iv) una cuarta unidad de bloqueo, adaptada para provocar que el nodo anterior desvíe la notificación del fallo cuando el nodo anterior no soporte la conversión de longitud de onda, o provoque que el nodo anterior absorba la notificación del fallo si el nodo anterior soporta la conversión de longitud de onda.

Preferiblemente, si el modelo de fallos creado mediante el módulo 10 de modelado cubre, además, los fallos del nodo no relacionados con el mecanismo de passthrough, el módulo 30 de conmutación con protección incluirá, además, un tercer submódulo de proceso, adaptado para realizar el procesado del traspaso cuando la señal de alarma se corresponda con un fallo de un nodo no relacionado con el traspaso; el tercer submódulo de proceso incluye, además: (i) una unidad de desvío, adaptada para provocar que la tarjeta de control del nodo que falla desvíe directamente los paquetes de control procedentes del nodo anterior; y (ii) una unidad de configuración del traspaso, adaptada para configurar todos los canales del Multiplexor Óptico para Añadir/Descartar (OADM) con el mecanismo de passthrough.

Preferiblemente, si el modelo de fallos creado mediante el módulo 10 de modelado cubre los fallos del nodo y/o los fallos del enlace relacionados con el traspaso, el primer submódulo de proceso se adapta, además, para ejecutar el proceso de steering con el ajuste de tiempo de retardo cuando la señal de alarma se corresponda con fallos del nodo y/o fallos del enlace asociados con el traspaso.

En la presente invención, la estructura interna de un equipo para la recuperación de fallos de un ROBR tal y como se describe lógicamente más arriba se elaborará con más detalle a continuación. Como se muestra en la Figura 1, la estructura de una red de ROBR se caracteriza por que: la estructura consiste en dos anillos inversos; cada anillo tiene N+1 canales de longitudes de onda, incluyendo 1 canal de control y N canales de datos; el canal de control se utiliza para transmitir los BCPs y los canales de datos se utilizan para transmitir los BDPs; el nodo del ROBR encapsula en un BDP los paquetes de datos que provienen de la subred local y que necesitan pasar a través de la red ROBR, y envía el BDP a un anillo (en función del modo de selección de anillo) mediante conmutación de ráfagas; los paquetes de datos dirigidos a una subred local se desvían a la subred correspondiente; además, el nodo del ROBR procesa o transfiere el BCP y el BDP correspondiente de acuerdo con la información recibida en el BCP del canal de control; el BDP enviado al nodo local se devuelve al paquete de datos original (como, por ejemplo, un paquete IP) y, a continuación se desvía a la subred correspondiente.

En la Tabla 3 se muestra el tipo de fallo, el método de detección y localización de fallos, y la señal enviada a la capa MAC y generada en función de las características del ROBR, de acuerdo con un modo de realización de la presente invención.

Tabla 3 Tipos de fallo del ROBR

Tipo de fallo: Detección y localización del fallo Señal enviada a la capa MAC

Fallo del nodo: Fallo software/hardware no relacionado con el traspaso Comprobación de consistencia, monitorización de pulsos Node_Degrade (degradación del nodo)

Fallo software/hardware relacionado con el traspaso, por ejemplo, fallo de la fuente de alimentación, extracción de la tarjeta o fallo del planificador: Igual que el RPR: alarma de “pérdida de keepalive (mantener activo)” C_Signal_Failure (fallo de señal)

Fallo del enlace: Corte en la fibra Detección de la potencia óptica del canal de control C_ Signal_Failure

Error de conexión del cable óptico (conexión incorrecta de los cables): Igual que el RPR: defecto en la conexión de cables C_ Signal_Failure

Fallo del canal: Control (P2P) Fallo del transmisor óptico Igual que el RPR: alarma de drive, potencia óptica de transmisión, detección ESNR/OSNR C_ Signal_Failure o C_ Signal_Degrade (degradación de la señal)

Fallo del receptor óptico: Igual que el RPR: potencia óptica del canal de control, detección ESNR/OSNR C_ Signal_Failure o C_ Signal_Degrade

Fallo de transmisión o amplificación de la longitud de onda de control: Detección de la potencia óptica y OSNR del canal de control C_ Signal_Failure o C_ Signal_Degrade

Datos: Fallo del transmisor óptico Igual que el RPR D_ Signal_Failure o D_ Signal_Degrade

Fallo del receptor óptico: Igual que el RPR D_ Signal_Failure o D_ Signal_Degrade

Fallo de transmisión o amplificación de la longitud de onda de datos: Aplicación de la tecnología de Red Exclusivamente Óptica (AON): alarma del dispositivo y monitorización D_ Signal_Failure o D_ Signal_Degrade

Fallo de un componente intermedio en el OADM: Aplicación de la tecnología existente: alarma del dispositivo y monitorización D_ Signal_Failure o D_ Signal_Degrade

Gestión: Conmutación forzada Notificación de orden de gestión al MAC Igual que el RPR: Forced_Switch

Conmutación manual: Notificación de orden de gestión al MAC Igual que el RPR: Manual_Switch

Para realizar el paso S102 que se muestra en la Figura 5, la presente invención aplica el método que se describe a continuación para detectar y localizar los fallos que se listan más arriba.

5 El canal de control experimenta una conversión óptica-eléctrica en cada nodo y las señales se convierten en señales eléctricas, por lo que, en la presente invención, se aplica un modo de detección de la capa física parecido al modo del RPR para la detección de fallos de los canales de control. La capa física envía una indicación de C_Signal_Failure al módulo de recuperación de fallos de la capa MAC después de la detección del fallo o una degradación importante del canal de control, y envía una indicación de C_Signal_Degrade al módulo de

10 recuperación de fallos de la capa MAC después de detectar una degradación de la señal del canal de control. Los fallos del enlace se detectan mediante un canal de control, y el método para indicar un fallo del enlace es el mismo que el método para indicar un fallo en el canal de control. Esto es debido a que, puesto que el canal de control forma parte del enlace correspondiente, un fallo del enlace conduce inevitablemente al fallo del canal de control correspondiente, pero un fallo del canal de control no conduce necesariamente a un fallo del enlace. Además, el

15 impacto del fallo del enlace es equivalente al impacto del fallo en el canal de control en el modo de conmutación de ráfagas.

Los fallos del software de un nodo se detectan mediante cualquier método de detección de fallos de software de la técnica anterior. Si el fallo del software no afecta al desvío de los paquetes de control y los paquetes de datos procedentes del nodo anterior, se enviará una indicación de fallo Node_Degrade; en caso contrario, se enviará una

20 indicación de C_Signal_Failure. Se utiliza la señal de alarma de hardware del nodo para la detección de fallos del hardware correspondiente. En función del hardware que falle, se envía la indicación de C_Signal_Failure o Node_Degrade.

Los fallos de los canales de datos se detectan mediante señales de alarma relevantes como por ejemplo una alarma del módulo transceptor y una alarma de monitorización del Multiplexor Óptico para Añadir/Descartar (OADM), y se envía una indicación de D_Signal_Failure (i)/D_Signal_Degrade (i) para indicar el fallo o la degradación de las señales del canal de datos número i.

Además, la presente invención aplica el modo de detección de fallos “keepalive” en la capa MAC por lo que la capa MAC de cada nodo envía periódicamente mensajes keepalive a través de los canales de control. Si falla el nodo siguiente al recibir los mensajes keepalive en un tiempo límite determinado, se estima que fallan el nodo anterior, el canal de control o el enlace de fibra, y el nodo del siguiente enviará una indicación de C_Signal_Failure al módulo de recuperación de fallos.

La presente invención aplica un método de recuperación de fallos diferente específico para cada tipo de fallo.

Para el fallo del nodo no relacionado con el desvío de señales (se recibe la indicación Node_Degrade), se aplica el mecanismo passthrough. En este caso, la tarjeta de control del nodo que falla desvía directamente el paquete de control procedente del nodo anterior y configura todos los canales del OADM del nodo que falla para que apliquen el mecanismo passthrough.

Para los fallos de enlace, fallos del canal de control y fallos del nodo relacionados con el traspaso (se recibe una indicación C_Signal_Failure/C_Signal_Degrade o una notificación de fallo) se aplica el método de recuperación de fallos steering con ajuste del tiempo de retardo. El nodo que detecta el fallo correspondiente difundirá la notificación de este tipo de fallo. El nodo actual que detecta y/o recibe la notificación de este tipo de fallo desviará el servicio que proceda de este nodo y lo transferirá a través del nodo que falla (denominado “servicio bajo protección”) al anillo en dirección al nodo de destino, y ajusta el tiempo de retardo y descarta el servicio bajo protección que atraviesa este nodo.

Para el fallo de un único canal de datos (se recibe una indicación D_Signal_Failure (i)/D_Signal_Degrade (i) o una notificación de fallo), el método de recuperación de fallos aplicado bajo la presente invención consiste en dejar de utilizar el canal de datos que falla. Si el fallo se localiza en un puerto de salida del nodo que detecta el fallo (denominado “fallo del canal de datos localizado en el puerto de salida”), el nodo que detecta el fallo dejará de utilizar el canal de datos que falla; y si el nodo no soporta la conversión de la longitud de onda, el nodo enviará una notificación de fallo al nodo anterior adyacente a través de un canal de control del anillo inverso; si el fallo se localiza en un puerto de entrada del nodo que detecta el fallo, el nodo enviará una notificación del fallo a través de un canal de control del anillo inverso. El nodo anterior que recibe la notificación del fallo del canal de datos desactiva el canal correspondiente. En este caso, si el nodo anterior no soporta la conversión de la longitud de onda, el nodo reenviará la notificación del fallo; si el nodo anterior soporta la conversión de la longitud de onda, el nodo absorberá la notificación del fallo.

La Figura 7 muestra el diagrama de flujo del método de recuperación de fallos del ROBR de acuerdo con el segundo modo de realización de la presente invención.

Basado en los principios y métodos anteriores, como se muestra en la Figura 7, el proceso de recuperación de fallos del ROBR de acuerdo con la presente invención incluye los pasos que se describen a continuación:

Paso S202: cada nodo detecta fallos utilizando los métodos anteriores de detección y localización de fallos, convierte el fallo detectado en una indicación de fallo definida en los métodos anteriores de detección y localización de fallos, y envía la indicación del fallo al módulo de recuperación de fallos de la capa MAC.

Paso S204: todos los nodos envían simultáneamente al módulo de recuperación de fallos de la capa MAC los paquetes de notificación de fallo recibidos.

Paso S206: el módulo de recuperación de fallos de la capa MAC utiliza un método de recuperación de fallos apropiado para gestionar las indicaciones de fallo propias y las notificaciones de fallo recibidas.

En el proceso de gestión de las indicaciones de fallo, el módulo de recuperación de fallos lleva a cabo las acciones apropiadas en función del tipo de indicación de fallo.

Si la indicación del fallo es Node_Degrade, la tarjeta de control del nodo actual desvía directamente el paquete de control procedente del nodo anterior y configura todos los canales del OADM para que apliquen el mecanismo passthrough.

Si la indicación del fallo es C_Signal_Failure y hay un anillo funciona normalmente o un anillo que tiene un fallo de C_Signal_Degrade, que puede enviar el servicio que se origina en el nodo actual y atravesar el nodo que falla hasta el nodo de destino, el nodo actual ajustará el tiempo de retardo del servicio y desviará el servicio al anillo en funcionamiento normal o el anillo con el fallo de C_Signal_Degrade. Después, el nodo actual difundirá la notificación de C_Signal_Failure a través de los canales de control del anillo interno y el anillo externo.

Si la indicación del fallo es C_Signal_Degrade y existe un anillo en funcionamiento normal que puede enviar el servicio originado en el nodo actual y atraviesa el nodo que falla hasta el nodo de destino, el nodo actual ajustará el tiempo de retardo del servicio y desviará el servicio al anillo en funcionamiento normal, y difundirá la notificación del fallo C_Signal_Degrade a través de los canales de control del anillo interno y el anillo externo.

Si la indicación de fallo es D_Signal_Failure(i)/D_Signal_Degrade(i) y el fallo del canal de datos está localizado en un puerto de salida, el nodo actual dejará de utilizar el canal de datos que falla; y, si el nodo actual no soporta la conversión de longitud de onda, el nodo actual enviará una notificación de fallo al nodo anterior contiguo a través de un canal de control del anillo inverso. Si el fallo del canal de datos está localizado en un puerto de entrada, el nodo actual enviará una notificación del fallo al nodo anterior contiguo a través de un canal de control del anillo inverso.

A continuación se describe un proceso de gestión de notificaciones de fallos. El módulo de recuperación de fallos lleva a cabo las acciones adecuadas en función el tipo de notificación de fallo recibida.

Si la notificación del fallo es del tipo C_Signal_Failure y el nodo actual ha recibido una notificación del mismo fallo de otro anillo, el nodo actual absorberá la notificación del fallo; en caso contrario, si existe un anillo en funcionamiento normal o un anillo con el fallo de C_Signal_Degrade, que puede enviar el servicio originado en el nodo actual y atravesar el nodo que falla hasta el nodo de destino, el nodo actual ajustará el tiempo de retardo del servicio y reenviará el servicio al anillo en funcionamiento normal o al anillo con el fallo de C_Signal_Degrade. Si la notificación del fallo proviene del anillo que falla, y el nodo actual es adyacente al nodo que falla (denominado como “nodo con fallo adyacente en un anillo común”), el nodo actual absorberá la notificación del fallo. En caso contrario, el nodo actual reenviará la notificación del fallo al nodo siguiente a través del canal de control.

Si la notificación del fallo es del tipo C_Signal_Degrade y el nodo actual ha recibido una notificación del mismo fallo del otro anillo, el nodo actual absorberá la notificación del fallo; en caso contrario, si existe un anillo en funcionamiento normal o un anillo que puede enviar el servicio originado en el nodo actual que atraviese el nodo que falla hasta el nodo de destino, el nodo actual ajustará el tiempo de retardo del servicio y desviará el servicio al anillo en funcionamiento normal. Si la notificación del fallo proviene del anillo que falla y el nodo actual es adyacente al nodo que falla (denominado como “anillo con fallo adyacente en un anillo común”), el nodo actual absorberá la notificación del fallo. En caso contrario, el nodo actual reenviará la notificación del fallo al nodo del siguiente a través de un canal de control.

Si la notificación del fallo es del tipo D_Signal_Failure(i)/D_Signal_Degrade(i), el nodo actual dejará de utilizar el canal de datos. Si el nodo actual no soporta conversión de longitud de onda, el nodo actual reenviará la notificación del fallo al nodo siguiente; si el nodo actual soporta conversión de longitud de onda, el nodo actual absorberá la notificación del fallo.

Se debería observar que el funcionamiento después de la recepción de la indicación de gestión es el mismo que después de la recepción de la señal C_Signal_Failure, excepto en el orden de preferencia del proceso. El funcionamiento equivale al proceso de un RPR, y no se repetirá aquí de nuevo.

A continuación se describe en detalle la presente invención con referencia a modos de realización preferidos y la Figura 8 � Figura 10.

La Figura 8 muestra la arquitectura lógica de un nodo de un ROBR en un modo de realización de la presente invención; la Figura 9 es un diagrama de flujo de un proceso de recuperación de fallos en un modo de realización de la presente invención; las Figuras 10A a 10F muestran diferentes estados de la gestión de fallos del ROBR en un modo de realización de la presente invención.

Como se muestra en la Figura 8, una arquitectura lógica de un nodo de un ROBR en un modo de realización de la presente invención incluye: un motor de reenvío, una unidad de ensamblaje, una unidad de desensamblaje, un módulo de selección de anillo, una base de datos de la topología con el tiempo de retardo, un grupo de recursos, dos OADM, dos módulos de monitorización de enlaces, dos módulos de proceso de mensajes, y dos planificadores (cada anillo tiene un planificador), un controlador OADM, un módulo de recuperación de fallos, un módulo de monitorización de keepalive, un módulo de descubrimiento de la topología, un módulo de Administración y Mantenimiento de Funcionamiento (OAM), un módulo de gestión del tiempo de retardo, y un módulo de monitorización del software/hardware.

El motor de desvío se adapta para reenviar paquetes de datos de acceso. Los paquetes de datos que necesitan pasar a través de la red ROBR se desvían a la unidad de ensamblaje, y los datos dirigidos al nodo local se desvían a la subred correspondiente.

La unidad de ensamblaje se adapta para ensamblar en Paquetes de Datos de Ráfagas (BDP) los paquetes de datos que necesitan añadirse a la red del ROBR; y la unidad de desensamblaje se adapta para recuperar los paquetes de datos de acceso a partir de los BDP y enviarlos al motor de reenvío.

El módulo de selección de anillo se adapta para consultar la base de datos de topología con el tiempo de retardo para determinar el anillo por el que enviar los datos de ráfagas y determinar el tiempo de retardo.

La base de datos de topología con el tiempo de retardo se adapta para almacenar la información de la topología del anillo completo y el tiempo de retardo requerido para la transmisión del nodo actual al resto de nodos. El tiempo de retardo lo actualiza el módulo de gestión del tiempo de retardo.

El módulo de proceso de mensajes se adapta para recibir los mensajes de los módulos del canal de control y del control y gestión local, y distribuir los mensajes. Las notificaciones de fallo dirigidas al nodo local se envían al módulo de recuperación de fallos; los BCP dirigidos al nodo local se envían al módulo de recepción y proceso, el cual configura un OADM mediante un controlador de OADM para recibir los BDP en función de la información en el BCP; los mensajes dirigidos a otros módulos locales de control y gestión se envían a los módulos de control y gestión correspondientes; al módulo de planificación se envían los BCP que necesitan desviarse, las notificaciones de fallos locales de salida y los mensajes de gestión y mantenimiento (como por ejemplo, mensajes de descubrimiento de topología y de gestión del tiempo de retardo).

El planificador se adapta para asignar recursos para los paquetes de gestión y control, BCP y BDP de acuerdo con la información en el grupo de recursos.

El grupo de recursos se adapta para almacenar los recursos de cada puerto de salida del nodo actual y el estado de utilización de dichos recursos.

Las funciones del módulo de descubrimiento de la topología y el módulo OAM son parecidas a las de un RPR.

El módulo de monitorización de keepalive se adapta para implementar la función de detección de fallo keepalive de la capa MAC. El controlador OADM es un interfaz de control del OADM, a través del que se controla el estado de cada canal del OADM (añadir, extraer o transferir).

El módulo de recuperación de fallos se adapta para recibir la información del fallo enviada desde el canal de control, el módulo de monitorización del enlace, el módulo de monitorización del software/hardware y el módulo de monitorización de keepalive, identificando el tipo de fallo y realizando las acciones adecuadas.

Como se muestra en la Figura 9, el proceso de recuperación de fallos de un módulo de recuperación de fallos incluye los pasos que se describen a partir de este momento.

Después de encender o reiniciar el sistema, el módulo de recuperación de fallos pasa a un estado inactivo, esperando la llegada de indicaciones de fallo y notificaciones de fallo; después de recibir una indicación de fallo local (esto es, detectar un fallo), el módulo de recuperación de fallos pasa el estado S300 de proceso de indicaciones de fallo. Después de recibir una notificación de fallo, el módulo de recuperación de fallos pasa al estado S400 de proceso de notificaciones de fallo. Después de completar el proceso de una indicación de fallo o de una notificación de fallo, el módulo de recuperación de fallos vuelve al estado inactivo, esperando nuevas indicaciones de fallo o notificaciones de fallo;

donde,

el procedimiento S300 de proceso de indicaciones de fallo incluye los siguientes pasos:

comienza el procedimiento S300 de indicaciones de fallo;

Paso S302: evaluar si la indicación del fallo es Node_Degrade. Si lo es, el procedimiento continúa en el paso S304, en caso contrario, continúa en el paso S306;

Paso S304: configurar los dos OADM para que apliquen el mecanismo passthrough, y configurar el canal de control para que aplique el desvío directo;

Paso S306: evaluar si la indicación del fallo es C_Signal_Fail/C_Signal_Degrade. Si lo es, el procedimiento continúa en el paso S308, en caso contrario, continúa en el paso S312;

Paso S308: actualizar la base de datos de la topología y deshabilitar el canal que falla;

Paso S310: difundir la notificación de fallo C_Signal_Fail/C_Signal_Degrade a través del canal de control del anillo interno y el anillo externo y, a continuación, terminar el proceso;

Paso S312: evaluar si la indicación del fallo es D_Signal_Fail/D_Signal_Degrade. Si lo es, el procedimiento continúa en el paso S314; en caso contrario, el proceso termina;

Paso S314: evaluar si el fallo del canal de datos se localiza en un puerto de salida. Si es así, el procedimiento continúa en el paso S316 o, en caso contrario, continúa en el paso S320;

Paso S316: actualizar el grupo de recursos, y deshabilitar el canal de datos que falla;

Paso S318: evaluar si el nodo soporta conversión de longitud de onda. Si lo hace, el proceso termina; en caso contrario, el proceso continúa en el paso S320; y

Paso S320: enviar la notificación de fallo D_Signal_Fail/D_Signal_Degrade al nodo anterior adyacente a través del canal de control del anillo inverso;

después termina el procedimiento S300 de proceso de la indicación de fallo y el módulo de recuperación de fallos vuelve al estado inactivo.

el procedimiento S400 de proceso de la notificación del fallo incluye los siguientes pasos:

comienza el procedimiento S400 de proceso de la notificación del fallo;

Paso S402: evaluar si se recibe la misma notificación de fallo. Si es así, el procedimiento continúa en el paso S416, o, en caso contrario, continúa en el paso S404;

Paso S404: determinar el tipo de mensaje de fallo. Si el mensaje de fallo es del tipo D_Signal_Failure/D_Signal_Degrade, el procedimiento continúa en el paso S406; si el mensaje de fallo es del tipo C_Signal_Failure/C_Signal_Degrade, el procedimiento continúa en el paso S410;

Paso S406: actualizar el grupo de recursos y deshabilitar el canal de datos que falla;

Paso S408: evaluar si el nodo soporta conversión de longitud de onda. Si se soporta la conversión de longitud de onda, el procedimiento continúa en el paso S416, o, en caso contrario, continúa en el paso S414;

Paso S410: actualizar la base de datos de la topología, y desviar el servicio que necesita protección en el nodo actual;

Paso S412: evaluar si el nodo es un nodo con fallo adyacente en un anillo común. Si lo es, el procedimiento continúa en el paso S416, o, en caso contrario, continúa en el paso S414;

Paso S414: desviar el mensaje de fallo al nodo siguiente a través del canal de control y, después, terminar el procedimiento de procesado; y

Paso S416: absorber el mensaje de fallo;

después termina el procedimiento S400 del proceso de la notificación de fallo y el módulo de recuperación de fallos vuelve al estado inactivo.

Las Figuras 10A a 10F muestran diferentes estados de la gestión de fallos del ROBR en el modo de realización que se muestra en la Figura 9.

La Figura 10A muestra un ROBR con ocho nodos, cada uno de los cuales tiene una estructura que se muestra en la Figura 8. Los nodos no son capaces de reenviar longitudes de onda, excepto los nodos 1, 3, 5 y 7. Antes de que ocurra el fallo, el nodo 0 envía datos al nodo 3 a través de un anillo externo mediante conmutación de ráfagas.

La Figura 10B muestra el caso de un fallo que ocurre en el nodo 2 sin afectar el desvío de mensajes. En este caso, el módulo de recuperación de fallos del nodo 2 recibe una indicación de fallo Node_Degrade del correspondiente módulo de monitorización de fallos. El módulo de recuperación de fallos del nodo 2 ejecuta los pasos S302 y S304 que se muestran en la Figura 9, esto es, configura la tarjeta de control del nodo actual para que aplique el mecanismo passthrough para desviar directamente los paquetes de control procedentes del nodo anterior, y configura todos los canales de ambos OADM mediante el controlador del OADM para que apliquen el mecanismo passthrough.

La Figura 10C muestra el caso en el que la fibra del anillo externo está cortada o el canal de control falla entre el nodo 1 y el nodo 2. En este caso, el módulo de monitorización del enlace del nodo 2 detecta una pérdida/fallo de las señales del canal de control del anillo externo, y envía una indicación C_Signal_Failure al módulo de recuperación de fallos del nodo 2, en el que el módulo de recuperación de fallos es equivalente al módulo 30 de conmutación con protección que incluye varios submódulos de proceso que se muestran en la Figura 6 (paso S306 en la Figura 9). El módulo de recuperación de fallos del nodo 2 actualiza la base de datos de la topología que almacena el tiempo de retardo, deshabilita el canal que falla (paso S308 en la Figura 9), y difunde la notificación C_Signal_Failure a través de los canales de control del anillo interno y el anillo externo (paso S310 en la Figura 9).

El módulo de proceso de mensajes del nodo 1 recibe la notificación C_Signal_Failure desde el canal de control del anillo interno y envía la notificación al módulo de recuperación de fallos del nodo 1. El módulo de recuperación de fallos del nodo 1 no ha recibido la notificación del mismo fallo desde el canal de control del anillo externo (paso S402 en la Figura 9), por lo que el módulo de recuperación de fallos actualiza la base de datos de la topología que almacena el tiempo de retardo (paso S410 en la Figura 9). La notificación del fallo no se recibe del anillo que falla (anillo externo), por lo que el nodo 1 no es un nodo adyacente al fallo en el anillo común. Por lo tanto, el nodo 1 desvía la notificación del fallo al nodo 0 a través del canal de control del anillo interno (paso S414 en la Figura 9).

Después de la recepción de la notificación C_Signal_Failure desde el canal de control del anillo interno, el módulo de recuperación de fallos del nodo 0 actualiza la base de datos de la topología que almacena el tiempo de retardo. En consecuencia, el módulo de selección de anillo desvía al anillo interno el servicio, que se envía al nodo 3 mediante el anillo externo, y después el servicio se envía al nodo 3 (paso S410 en la Figura 9). Al mismo tiempo, la notificación del fallo se envía, además, a los nodos siguientes a través del canal de control del anillo interno (paso S414 en la Figura 9).

Después de que el nodo 7 reciba la notificación C_Signal_Failure desde el canal de control del anillo interno, el módulo de recuperación de fallos del nodo 7 actualiza la base de datos de la topología que almacena el tiempo de retardo y envía, además, la notificación del fallo a los nodos siguientes a través del canal de control del anillo interno.

Cuando el nodo 6 recibe la notificación C_Signal_Failure desde el canal de control del anillo interno, detecta que el nodo actual ha recibido una notificación del mismo fallo desde el canal de control del anillo externo. Por lo tanto, el nodo 6 absorbe la notificación C_Signal_Failure que se difunde a lo largo del canal de control del anillo interno (paso S416 en la Figura 9).

Después de que los nodos 3, 4, 5 y 6 reciban la notificación C_Signal_Failure desde el canal de control del anillo externo, el módulo de recuperación de fallos correspondiente actualiza la base de datos de la topología que almacena el tiempo de retardo y envía, además, la notificación del fallo a los nodos siguientes a través del canal de control del anillo externo. Cuando la notificación C_Signal_Failure que se difunde a lo largo del canal de control del anillo externo llega hasta el nodo 7, el nodo 7 ha recibido la notificación C_Signal_Failure del canal de control del anillo interno. Por lo tanto, el nodo 7 absorbe la notificación C_Signal_Failure que se difunde a lo largo del canal de control del anillo externo (paso S416 en la Figura 9).

La Figura 10D muestra el caso en el que tanto la fibra del anillo interno y la fibra del anillo externo están cortadas o los canales de control de ambos anillos fallan entre el nodo 1 y el nodo 2. En este caso, el módulo de monitorización de enlaces del nodo 2 detecta la pérdida/el fallo de las señales del canal de control del anillo externo y envía una indicación C_Signal_Failure al módulo de recuperación de fallos del nodo 2 (paso S306 en la Figura 9). El módulo de recuperación de fallos del nodo 2 actualiza la base de datos de la topología que almacena el tiempo de retardo, deshabilita el canal que falla (paso S308 en la Figura 9), y difunde la notificación C_Signal_Failure a través de los canales de control del anillo interno y el anillo externo (paso S310 en la Figura 9). Al mismo tiempo, el módulo de monitorización de enlaces del nodo 1 detecta la pérdida/el fallo de las señales del canal de control del anillo interno y ejecuta la operación como el nodo 2.

La notificación C_Signal_Failure(2) que difunde el nodo 2 a través del canal de control del anillo interno se pierde debido al corte en la fibra del anillo interno. La notificación C_Signal_Failure(1) que difunde el nodo 1 a través del canal de control del anillo externo se pierde debido al corte en la fibra del anillo externo.

Después de que los nodos 3, 4, 5, 6, 7 y 0 reciban sucesivamente la notificación C_Signal_Failure(2) (que se difunde a través del anillo externo) desde el canal de control del anillo externo, cada nodo actualiza la base de datos de la topología que almacena el tiempo de retardo (paso S410 en la Figura 9) y envía, además, la notificación de fallo a los nodos siguientes a través del canal de control del anillo externo. Después de que el nodo 0 actualice la base de datos de la topología que almacena el tiempo de retardo en el nodo 0, el servicio que antes se enviaba al nodo 3 a través del anillo externo se desvía al anillo interno, y a continuación se envía al nodo 3 (como se muestra en la Figura 10D). Cuando la notificación C_Signal_Failure(2), que el nodo 2 difunde a través del anillo externo, llega al nodo 1, el nodo 1 actualiza la base de datos de la topología que almacena el tiempo de retardo en el nodo 1. Al mismo tiempo, debido a que la notificación del fallo se recibe a través del anillo que falla (anillo externo) y el nodo 1 es un nodo adyacente al fallo (denominado “punto adyacente al fallo en un anillo común”), por lo que el nodo 1 absorbe la notificación del fallo.

La notificación C_Signal_Failure(1), que el nodo 1 difunde a través del canal de control del anillo interno, atraviesa sucesivamente los nodos 0, 7, 6, 5, 4, 3 y 2. Los nodos 0, 7, 6, 5, 4 y 3 actualizan la base de datos de la topología que almacena el tiempo de retardo en el nodo respectivo (paso S410 en la Figura 1), y desvía la notificación del fallo a través del canal de control del anillo interno. El nodo 2 absorbe la notificación del fallo porque es un nodo adyacente al fallo en el anillo común de la notificación del fallo.

La Figura 10E muestra el caso de que, entre el nodo 6 y el nodo 7, el anillo interno incurre de nuevo en una degradación de la señal después de que ocurra el fallo descrito en la Figura 10C. El nodo 6 detecta la degradación de la señal en el canal de control del anillo interno, y envía una indicación de fallo C_Signal_Degrade al módulo de recuperación de fallos del nodo 6 (paso S306 en la Figura 9). El nodo 6 actualiza la base de datos de la topología que almacena el tiempo de retardo (paso S308 en la Figura 9), y se establece el número de saltos del canal del anillo interno entre el nodo 6 y el nodo 7 en 254 (número máximo de nodos soportados por el anillo). Además, el nodo 6 difunde la notificación de fallo C_Signal_Degrade a través de los canales de control del anillo interno y el anillo externo (paso S310 en la Figura 9).

La notificación del fallo C_Signal_Degrade en el canal de control del anillo externo llega sucesivamente a los nodos 7, 0 y 1. Los nodos 7, 0 y 1 actualizan la base de datos de la topología que almacena el tiempo de retardo en el nodo respectivo, se establece el número de saltos del canal del anillo interno entre el nodo 6 y el nodo 7 en 254 (número máximo de nodos soportados por el anillo), y se difunde a través del canal de control del anillo externo (pasos S410 y S414 en la Figura 9). Después, el nodo 0 actualiza la base de datos de la topología que almacena el tiempo de retardo en el nodo 0, y el servicio enviado al nodo 3 a través del anillo interno no se reenviará a través del anillo externo debido a que el fallo por el corte de fibra del anillo externo entre el nodo 1 y el nodo 2 es más grave (marcado como “deshabilitado” en la base de datos de la topología que almacena el tiempo de retardo, equivalente a un número infinito de saltos). El módulo de selección de anillo seleccionará, a pesar de todo, el anillo interno para la transmisión del servicio dirigido al nodo 3 aplicando el principio del número mínimo de saltos. La notificación del fallo desviada por el nodo 1 a través del anillo externo se pierde debido al corte de fibra del anillo externo.

La notificación del fallo C_Signal_Degrade en el canal de control del anillo interno pasa sucesivamente a través de los nodos 5, 4, 3 y 2. Los nodos 5, 4, 3, y 2 actualizan la base de datos de la topología que almacena el tiempo de retardo en el nodo respectivo, se establece el número de saltos del anillo interno entre el nodo 6 y el nodo 7 en 254 (número máximo de nodos soportados por el anillo), y se desvía a través del canal de control del anillo interno (pasos S410 y S414 en la Figura 9). Cuando el nodo 1 recibe la notificación del fallo del canal de control del anillo interno, la notificación del fallo se absorbe debido a que el nodo 1 ha recibido una notificación del mismo fallo a través del anillo externo (pasos S402 y S416 en la Figura 9).

La Figura 10F muestra el caso de un fallo de un canal de datos (Wi) localizado en el puerto de salida del anillo externo entre el nodo 2 y el nodo 3 en el ROBR que se muestra en la Figura 10A. El módulo de detección hardware del canal de datos del nodo 2 detecta el fallo y envía una indicación de D_Signal_Failure(Wi) al módulo de recuperación de fallos del nodo 2. El módulo de recuperación de fallos del nodo 2 actualiza el grupo de recursos para marcar la longitud de onda Wi en el puerto de salida del anillo externo como deshabilitada (paso S316 en la Figura 9). Debido a que el nodo 2 no soporta la conversión de longitud de onda, el nodo 2 envía una notificación D_Signal_Failure(Wi) al nodo 3 adyacente anterior a través del canal de control del anillo interno (paso S320 en la Figura 9). Después de recibir la notificación D_Signal_Failure(Wi) del anillo interno, el nodo 1 actualiza el grupo de recursos para marcar la longitud de onda Wi en el puerto de salida del anillo externo como deshabilitada (paso S406 en la Figura 9). Debido a que el nodo 1 soporta conversión de longitudes de onda, el nodo 1 absorbe la notificación del fallo (paso S416 en la Figura 9). Después de terminar el proceso de protección anterior, el servicio enviado por el nodo 0 al nodo 3 se sigue transmitiendo a través del anillo externo. No obstante, el servicio puede utilizar cualquier canal de datos entre el nodo 0 y el nodo 1; pero entre el nodo 1 y el nodo 3 únicamente puede utilizar canales de datos distintos del canal con longitud de onda Wi. El servicio transportado en el canal con longitud de onda Wi entre el nodo 0 y el nodo 1 se debe someter a una conversión de longitud de onda y desviar a los canales de otras longitudes de onda en el puerto de salida del nodo 1.

Evidentemente, el método de recuperación de fallos bajo la presente invención no es aplicable únicamente al ROBR de una estructura de anillo dual, sino también al ROBR de una estructura multianillo.

En último término, los modos de realización de la presente invención proporcionan los beneficios que se detallan a continuación.

La recuperación de fallos del ROBR y los métodos de la misma proporcionados por la presente invención constituyen una solución efectiva para la gestión de fallos en el caso en el que el canal de control esté separado del canal de datos en el ROBR. Además, en la presente invención se proporcionan múltiples métodos de detección y localización que cubren los canales de datos y los canales de control para lograr consistencia entre el canal de control y el canal de datos durante una acción de recuperación de fallos; después del fallo de un nodo y/o un enlace del ROBR se logra una rápida protección y recuperación de los servicios; se mejora la robustez del ROBR y se logra que sea una red de funcionamiento fiable; y se permite añadir y eliminar nodos sin la interrupción de los servicios.

Los modos de realización descritos más arriba son únicamente los mejores de esta invención, y no pretenden limitar el alcance de protección de esta invención. Los técnicos en este campo pueden realizar varios cambios y variaciones a la presente invención. Para aquellos experimentados en la técnica, es evidente que se pueden realizar varias modificaciones y variaciones a esta invención sin apartarse del alcance de la invención. La invención pretende cubrir las modificaciones y variaciones suponiendo que entran en el alcance de protección definido por las siguientes reivindicaciones.

Claims

REIVINDICACIONES

1.

Un método para gestionar el fallo de un Anillo Óptico de Ráfagas Adaptable, ROBR, que comprende: aplicar un mecanismo steering (dirección) cuando falla un canal de control; y aplicar, cuando falla un canal de datos, un mecanismo para dejar de utilizar el canal de datos que falla y continuar

utilizando los canales de datos que funcionan correctamente.
2.

El método de acuerdo con la reivindicación 1, que comprende, además: configurar (paso S102) un modelo de fallos en función de las características del ROBR, donde el modelo de fallos cubre al menos los fallos del canal de control y los fallos del canal de datos.
3.

El método de acuerdo con la reivindicación 2, que comprende, además: enviar (paso S104) a la capa de Control de Acceso al Medio, MAC, una señal de alarma del fallo correspondiente cuando ocurre al menos un fallo cubierto por el modelo de fallos.
4.

El método de acuerdo con cualquiera de las reivindicaciones 1 a 3, donde los tipos de fallo de los canales de control comprenden el fallo de la señal de control y degradación de la señal de control, y el mecanismo steering cuando falla el canal de control comprende:

desviar un servicio si el tipo de fallo de un canal de control en un anillo es un fallo de la señal de control;

desviar un servicio si el tipo de fallo de un canal de control en un anillo es una degradación de la señal de control y el anillo inverso funciona normalmente; y

mantener sin cambios la dirección del anillo de proceso actual si el tipo de fallo de un canal de control en un anillo es una degradación de la señal de control y el tipo de fallo en el anillo inverso es un fallo de la señal de control.
5. El método de acuerdo con cualquiera de las reivindicaciones 1 a 3, donde el modo para dejar de utilizar el canal de datos que falla comprende:

dejar de utilizar, por parte de un primer nodo, el canal de datos que falla si el fallo del canal de datos que falla se localiza en un puerto de salida del primer nodo del fallo; y enviar una notificación del fallo a un nodo adyacente anterior a través de un canal de control del anillo inverso si el primer nodo no soporta conversión de la longitud de onda;

enviar una notificación del fallo a través de un canal de control del anillo inverso si el fallo del canal de datos se localiza en el puerto de entrada del primer nodo; y

configurar, por parte del nodo adyacente anterior que recibe la notificación del fallo del canal de datos, el canal de datos que falla como deshabilitado; desviar la notificación del fallo si el nodo adyacente anterior no soporta conversión de la longitud de onda; y absorber la notificación del fallo si el nodo adyacente anterior soporta conversión de la longitud de onda.
6.

El método de acuerdo con cualquiera de las reivindicaciones 1 a 5, que comprende, además:

aplicar el mecanismo steering con ajuste del tiempo de retardo en el caso de un fallo de enlace o un fallo asociado a un traspaso; y/o aplicar un mecanismo de traspaso en el caso de un fallo de un nodo no relacionado con la desviación de la señal.
7.

El método de acuerdo con la reivindicación 6, donde el mecanismo de traspaso comprende: forzar a una tarjeta de control del nodo que falla para que desvíe directamente el paquete de control anterior; y configurar todos los canales del Multiplexor Óptico para Añadir/Descartar, OADM, como traspaso.
8.

El método para gestionar fallos de acuerdo con cualquiera de las reivindicaciones 1 a 5, donde el mecanismo steering se acompaña por un ajuste del tiempo de retardo.
9.

El método de gestión de fallos de acuerdo con la reivindicación 8, donde el mecanismo steering con ajuste del tiempo de retardo comprende:

difundir la notificación del fallo por parte de un segundo nodo que detecta el fallo; y

desviar, por parte del primer nodo que detecta y/o recibe localmente la notificación del fallo, el servicio que viene del primer nodo y pasa a través del segundo nodo al anillo en dirección al nodo de destino, y ajustar el tiempo de retardo, y descartar el servicio bajo protección que pasa a través del primer nodo.
10.

El método de acuerdo con cualquiera de las reivindicaciones 1 a 9, donde se determina el tipo de fallo mediante detección y localización de fallos; y la detección del fallo se realiza en el modo de separación del canal de datos del canal de control.
11.

Un equipo de gestión de recuperación de fallos de un Anillo Óptico de Ráfagas Adaptable (ROBR), que comprende:

un módulo (30) de conmutación con protección, adaptado para aplicar un mecanismo steering cuando falla un canal de control; y, cuando falla un canal de datos, aplicar un mecanismo para dejar de utilizar el canal de datos que falla y continuar la utilización de los canales de datos que funcionan correctamente.
12.

El equipo de acuerdo con la reivindicación 11, que comprende, además:

un módulo (10) de modelado, adaptado para establecer un modelo de fallos en función de las características del ROBR, donde el modelo de fallos cubre, al menos, los fallos del canal de control y los fallos del canal de datos.
13.

El equipo de acuerdo con la reivindicación 12, que comprende, además:

un módulo (20) de generación de señal, adaptado para enviar una señal de alarma de fallo apropiada a la capa MAC cuando ocurre al menos un fallo cubierto por el modelo de fallos.
14.

El equipo de acuerdo con cualquiera de la reivindicación 13, donde el módulo (30) de conmutación con protección comprende:

un primer submódulo de proceso, adaptado para ejecutar el mecanismo steering con ajuste del tiempo de retardo si la señal de alarma se corresponde con un fallo de un canal de control; y

un segundo submódulo de proceso, adaptado para dejar de utilizar el canal de datos que falla y continuar utilizando los canales de datos que funcionan correctamente, si la señal de alarma se corresponde con un fallo del canal de datos.
15. El equipo de la reivindicación 14, donde:

si el modelo de fallos cubre fallos de nodos no relacionados con el traspaso, el módulo (30) de conmutación con protección comprende, además: un tercer submódulo de proceso, adaptado para ejecutar la acción de traspaso cuando la señal de alarma se corresponde con un fallo del nodo no relacionado con el traspaso;

si el modelo de fallos cubre fallos de nodos y/o fallos de enlaces relacionados con el traspaso, el primer submódulo de proceso se adapta, además, para ejecutar el mecanismo steering con ajuste del tiempo de retardo cuando la señal de alarma se corresponde con los fallos de nodos y/o fallos de enlaces relacionados con el traspaso.
16.

El equipo de la reivindicación 15, donde el tercer submódulo de proceso comprende:

una unidad de desvío, adaptada para forzar que la tarjeta de control del nodo que falla desvíe directamente el paquete de control procedente del nodo anterior; y una unidad de configuración del traspaso, adaptada para configurar todos los canales de OADM del nodo que falla para que apliquen el mecanismo passthrough.
17.

El equipo de acuerdo con cualquiera de las reivindicaciones 14 a 16, donde el primer submódulo de proceso comprende:

una unidad de difusión, adaptada para hacer que un segundo nodo que detecta el fallo difunda la notificación del fallo;

una unidad de configuración del tiempo de retardo, adaptada para hacer que un primer nodo, que detecta y/o recibe localmente la notificación del fallo, desvíe un servicio que viene del primer nodo y atraviesa el segundo nodo del anillo en dirección a un nodo de destino, y para ajustar el tiempo de retardo; y

una unidad de descarte, adaptada para descartar un servicio que atraviesa el primer nodo y necesita protección.
18. El equipo de acuerdo con cualquiera de las reivindicaciones 14 a 16, donde el segundo submódulo de proceso comprende:

una primera unidad de bloqueo, adaptada para hacer que el primer nodo deje de utilizar el canal de datos que falla si el fallo está localizado en un puerto de salida del primer nodo del fallo; y hacer que el primer nodo envíe una notificación del fallo al nodo adyacente anterior a través del canal de control del anillo inverso si el primer nodo no soporta conversión de longitud de onda;

una segunda unidad de bloqueo, adaptada para hacer que el primer nodo envíe una notificación de fallo a través de un canal de control del anillo inverso si el fallo está localizado en un puerto de entrada del primer nodo;

una tercera unidad de bloqueo, adaptada para hacer que el nodo adyacente anterior, que recibe la notificación del fallo del canal de datos, deshabilite el canal de datos correspondiente; y

una cuarta unidad de bloqueo, adaptada para hacer que el nodo adyacente anterior desvíe la notificación del fallo si el nodo adyacente anterior no soporta conversión de longitud de onda; o hacer que el nodo adyacente anterior 5 absorba la notificación del fallo si el nodo anterior soporta conversión de longitud de onda.
19. El equipo de acuerdo con cualquiera de las reivindicaciones 14 a 16, donde el módulo (20) de generación de señal comprende un submódulo de monitorización de enlaces, adaptado para determinar el tipo de fallo mediante la detección y localización de fallos; y la detección de fallos se realiza en el modo de separación del canal de datos del canal de control.