ES2322691T3 - Conmutador de encaminamiento para reencaminar trafico dinamicamente debido a la deteccion de un enlace erroneo. - Google Patents

Abstract

Un conmutador de encaminamiento para su uso en una red de comunicaciones en la que una pluralidad de conmutadores de encaminamiento están interconectados por enlaces de comunicación en un primer anillo y un segundo anillo, conmutador de encaminamiento que comprende: uno o más transceptores (30, 32) que pueden conectarse a enlaces (34, 36) de comunicación asociados para su conexión a uno o más conmutadores de encaminamiento adyacentes en dicha red; una tabla (47) de encaminamiento; una matriz (50) de conmutación dispuesta para encaminar tráfico hacia y desde dichos uno o más transceptores (30, 32) basándose en la tabla (47) de encaminamiento, y uno o más procesadores (46) adaptados para: comprobar la calidad de dichos enlaces de comunicación entre dichos uno o más conmutadores de encaminamiento adyacentes; detectar si uno o más primeros enlaces de dichos enlaces de comunicación no cumplen con un umbral de calidad; transmitir información que identifica dichos uno o más primeros enlaces desde el conmutador de encaminamiento hacia otros conmutadores de encaminamiento en dicha red; corregir dicha tabla (47) de encaminamiento para reencaminar el tráfico afectado, de modo que el tráfico afectado no atraviese dichos uno o más primeros enlaces debido a que dichos uno o más primeros enlaces son erróneos; y encaminar tal tráfico afectado hacia un nodo destino, basándose en dicha tabla de encaminamiento corregida, en una dirección por dicho anillo diferente de una dirección con la que se habría desplazado hacia dicho nodo destino en caso de que dichos uno o más primeros enlaces no hubieran sido erróneos; caracterizado porque: la matriz (50) de conmutación está dispuesta para encaminar tráfico hacia y desde dichos uno o más transceptores (30, 32) de modo que durante la operación normal el tráfico fluye hacia otros conmutadores de encaminamiento en dicha red tanto por el primer anillo como el segundo anillo; y el procesador (46) está dispuesto para corregir dicha tabla (47) de encaminamiento para crear un trayecto de reencaminamiento teniendo en cuenta un número de saltos para el tráfico entre un conmutador fuente y uno destino en dicho trayecto de reencaminamiento, una tasa de transmisión de errores de bits normalizada acumulativa desde el conmutador fuente y el destino en dicho trayecto de reencaminamiento y un nivel de congestión de tráfico entre el conmutador fuente y el destino en dicho trayecto de reencaminamiento.

Description

Conmutador de encaminamiento para reencaminar tráfico dinámicamente debido a la detección de un enlace erróneo.

Campo de la invención

La presente invención se refiere a redes de comunicación y, en particular, a redes que emplean anillos.

Antecedentes

Dado que los servicios de datos son cada vez más del tipo misión crítica para los negocios, las disrupciones de servicio son cada vez más costosas. Un tipo de disrupción de servicio que es muy preocupante es la interrupción de un tramo, que puede deberse a fallos en la instalación o bien en el equipo. Las portadoras de tráfico de voz han diseñado tradicionalmente sus redes para que sean robustas en el caso de interrupciones de la instalación, por ejemplo roturas de fibras. Tal como se establece en las especificaciones de GR-253 y GR-499 de Telcordia para las redes de anillo óptico en la infraestructura de telecomunicaciones, no debe producirse una disrupción de la voz u otros servicios protegidos durante más de 60 milisegundos por una única interrupción de la instalación. Esto incluye hasta 10 milisegundos para la detección de una interrupción de la instalación, y hasta 50 milisegundos para reencaminar el tráfico.

Una tecnología significativa para implementar redes con capacidad de supervivencia que cumplen los requisitos anteriores han sido los anillos SONET. Una característica fundamental de tales anillos es que hay uno (o más) enlaces físicos independientes que conectan los nodos adyacentes en el anillo. Cada enlace puede ser unidireccional, por ejemplo permitir que el tráfico pase en una única dirección, o puede ser bidireccional. Un nodo se define como un punto en el que el tráfico puede entrar o salir del anillo. Un tramo individual conecta dos nodos adyacentes, estando constituido un tramo por todos los enlaces que conectan directamente los nodos. Un tramo se implementa normalmente como una conexión de dos fibras o bien de cuatro fibras entre los dos nodos. En el caso de las dos fibras, cada enlace es bidireccional, con la mitad del tráfico en cada fibra yendo en la dirección "horaria" (o dirección 0), y la otra mitad yendo en la dirección "antihoraria" (o dirección 1 opuesta a la dirección 0). En el caso de las cuatro fibras, cada enlace es unidireccional, portando dos fibras el tráfico en la dirección 0 y portando dos fibras el tráfico en la dirección 1. Esto permite mantener un trayecto de comunicación entre cualquier par de nodos en una única dirección por el anillo cuando el tramo físico entre cualquier par individual de nodos se pierde. En el resto de este documento se hará referencia sólo a la dirección 0 y dirección 1 para generalizar.

Hay 2 tipos principales de anillos SONET: anillos conmutados de trayecto unidireccional (UPSR) y anillos conmutados en línea bidireccional (BLSR). En el caso de UPSR, la operación de anillo robusta se consigue enviando datos en ambas direcciones por el anillo para todo el tráfico internodal en el anillo. Esto se muestra en la figura 1. Esta figura muestra un anillo de N nodos formado por nodos (dispositivos de red) numerados desde el nodo 0 hasta el nodo N-1 e interconectados por tramos. En este documento, los nodos están numerados en orden ascendente en la dirección 0 partiendo de 0 por conveniencia de notación. Un enlace que pasa tráfico desde el nodo i hacia el nodo j se denomina dij. Un tramo se denomina sij, que es equivalente a sji. En este documento, el término tramo se usará para una descripción general. El término enlace se usará sólo cuando sea necesario por motivos de precisión. En este diagrama, el tráfico desde el nodo 0 hacia el nodo 5 se muestra tomando rutas físicas (flechas en negrita) tanto en la dirección 0 como la dirección 1. (En este documento, los nodos se enumerarán secuencialmente de un modo ascendente en la dirección 0 por motivos de conveniencia. El nodo 0 se usará para los ejemplos). En el extremo receptor, un receptor especial implementa una "conmutación de extremo de cola", en la que el receptor selecciona los datos de una de las direcciones por el anillo. El receptor puede hacer esta elección basándose en diversos mecanismos de control de rendimiento (PM) soportados por SONET. Este mecanismo de protección tiene la ventaja de que es muy simple, porque no es necesaria mensajería a nivel de anillo para comunicar una ruptura de tramo a los nodos en el anillo. Más bien, los elementos de red de PM incorporados en SONET garantizan que un tramo "malo" no afecta a la conectividad física entre nodos, dado que no se pierden datos sean cuales fueran debido a un único fallo de tramo.

Desafortunadamente, hay que pagar un alto precio para esta protección. Dependiendo del patrón de tráfico en el anillo, un UPSR necesita reservar de un 100% de capacidad adicional (para un patrón "de rueda" única) a un 300% de capacidad adicional (para un patrón "de malla" uniforme) hasta tanto como un (N-1)* 100% de capacidad adicional (para un anillo de N nodos con un patrón de vecino más próximo, tal como el mostrado en la figura 1) para la protección.

En el caso de un BLSR de dos fibras, mostrado en la figura 2A, los datos desde cualquier nodo dado hacia otro normalmente de desplazan en una dirección (flechas continuas) por el anillo. La comunicación de datos se muestra entre los nodos 0 y 5. La mitad de la capacidad de cada anillo se reserva para proteger frente a fallos de tramo en el otro anillo. Las flechas discontinuas ilustran un anillo que normalmente no se usa para el tráfico entre los nodos 0 y 5 excepto en el caso de un fallo de tramo o en el caso de una congestión de tráfico poco habitual.

En la figura 2B, el tramo entre los nodos 6 y 7 ha experimentado un error. La conmutación de protección se proporciona ahora invirtiendo la dirección de la señal desde el nodo 0 cuando se encuentra con el tramo erróneo y usando la capacidad de anillo en exceso para encaminar la señal hacia el nodo 5. Esta conmutación, que tiene lugar en los mismos nodos que detectan el error, es muy rápida y está diseñada para cumplir con el requisito de 50 milisegundos.

La protección de BLSR necesita un 100% de capacidad adicional con respecto a la que sería necesaria para un anillo no protegido, dado que el equivalente del ancho de banda de un anillo completo no se usa excepto en el caso de un fallo de tramo. A diferencia de un UPSR, un BLSR necesita una señalización a nivel de anillo entre los nodos para comunicar la información en cortes de tramo y una coordinación apropiada de los nodos para iniciar la protección de anillo.

Aunque estas tecnologías de protección de anillo SONET han demostrado ser en sí mismas robustas, pierden capacidad de manera extrema. Adicionalmente, tanto los UPSR como los BLSR dependen estrechamente de las capacidades proporcionadas por SONET para su operación, y por tanto no pueden mapearse fácilmente con mecanismos de transporte distintos de SONET.

Lo que se necesita es una tecnología de protección en la que no se consuma capacidad de red adicional durante la operación "normal" (es decir, cuando todos los tramos de anillo son operacionales), que está ligada de una manera menos estrecha con un protocolo de transporte específico, y que está diseñada para cumplir con el requisito de conmutación de 50 milisegundos de Telcordia.

El documento US-A-4527270 da a conocer un conmutador de encaminamiento con protección frente a error o ruptura.

Sumario

Se describe una técnica de restauración y protección de red que utiliza de manera eficiente el ancho de banda total en la red para superar los inconvenientes de las redes descritas anteriormente, que no está ligada a un protocolo de transporte específico tal como SONET, y que está diseñada para cumplir con el requisito de conmutación de 50 milisegundos de Telcordia. La red dada a conocer incluye dos anillos, en los que un primer anillo transmite datos en una dirección "horaria" (o dirección 0), y el otro anillo transmite datos en una dirección "antihoraria" (o dirección 1 opuesta a la dirección 0). También pueden usarse anillos adicionales. El tráfico se retira del anillo por el nodo destino.

Durante las operaciones normales (es decir, todos los tramos operacionales y no degradados), los datos entre los nodos fluyen en el anillo que proporciona el trayecto de menor coste hacia el nodo destino. Si la utilización de tráfico se distribuye uniformemente por toda la red, el trayecto de menor coste es normalmente el mínimo número de saltos hacia el nodo destino. Por tanto, ambos anillos se utilizan en su totalidad durante las operaciones normales. Cada nodo determina el trayecto de menor coste desde el mismo hacia cada otro nodo en el anillo. Para hacer esto, cada nodo debe conocer la topología de red.

Un nodo controla el estado de cada enlace para el que está en el extremo receptor, por ejemplo cada uno de sus enlaces de entrada, para detectar un error. La detección de un error de este tipo produce un mensaje de radiodifusión de estado de enlace de la máxima prioridad que va a enviarse hacia todos los nodos. El procesamiento en cada nodo de la información contenida en el mensaje de radiodifusión de estado de enlace da como resultado la reconfiguración de una tabla de encaminamiento dentro de cada nodo para identificar el encaminamiento óptimo del tráfico fuente hacia el nodo destino tras el error. Por tanto, todos los nodos conocen el estado de la red y todos identifican independientemente el trayecto de encaminamiento óptimo hacia cada nodo destino cuando hay un error en cualquiera de los enlaces. El procesamiento está diseñado para ser extremadamente eficiente para maximizar la velocidad de conmutación.

Opcionalmente, si se desea aumentar adicionalmente la velocidad de conmutación, puede usarse una etapa intermedia. Un nodo que detecta un error de enlace notifica a su vecino en el otro lado de ese tramo que un enlace ha fallado. Cualquier nodo que detecta un fallo de enlace de entrada o que recibe una notificación de este tipo desvía el tráfico de llegada dirigido a ese tramo por el otro anillo. El tráfico se desviará sólo temporalmente hasta que se haya completado el reencaminamiento de tráfico descrito anteriormente.

Dado que los enlaces restantes tendrán ahora más tráfico de datos debido al enlace fallido, se da menor prioridad al tráfico denominado tráfico "no protegido" y puede abandonarse o retardarse en favor del tráfico "protegido". Se describen técnicas específicas para identificar un enlace fallido, comunicando el enlace fallido a los otros nodos, diferenciando entre clases de tráfico protegidas y no protegidas, y actualizando las tablas de encaminamiento. Aunque las realizaciones descritas transmiten paquetes de datos, la invención puede aplicarse a cualquier red que transmite tramas, células o que usa cualquier otro protocolo. Las tramas y células son similares a los paquetes porque todos contienen información de control y datos que pertenece al menos a la fuente y el destino para los datos. Una única trama puede contener múltiples paquetes, dependiendo del protocolo. Una célula puede ser de tamaño fijo, dependiendo del protocolo.

Breve descripción de los dibujos

La figura 1 ilustra las rutas físicas internodales que toma el tráfico desde el nodo 0 hacia el nodo 5 usando UPSR SONET, en las que un fallo de tramos entre cualquier par individual de nodos suprime sólo una de las dos rutas físicas distintas para el tráfico.

La figura 2A ilustra una ruta física internodal que toma el tráfico desde el nodo 0 hacia el nodo 5 usando BLSR de dos fibras SONET. La mitad de la capacidad de cada anillo se reserva para la protección, y la mitad se usa para transportar el tráfico regular. El anillo representado con líneas discontinuas es el anillo en el que se usa capacidad de protección para reencaminar el tráfico debido al fallo de tramo mostrado.

La figura 2B ilustra el trayecto bidireccional que toma el tráfico desde el nodo 0 hacia el nodo 5 usando la estructura de BLSR SONET de la figura 2A cuando hay un fallo en el enlace entre los nodos 6 y 7. El tráfico da la vuelta cuando se encuentra con un enlace fallido.

La figura 3 ilustra una red según una realización de la presente invención y, en particular, ilustra una ruta física internodal que toma el tráfico desde el nodo 0 hacia el nodo 5.

La figura 4 ilustra la red de la figura 3 tras haberse producido un fallo en el tramo entre los nodos 6 y 7. Cuando se produce un fallo que afecta a un enlace o un tramo en el trayecto inicial (por ejemplo, entre los nodos 0 y 5), el tráfico se reencamina en el nodo de entrada para desplazarse en la otra dirección por el anillo para alcanzar el nodo destino.

La figura 5 ilustra el estado intermedio opcional de la red (basándose en el tráfico de desvío desde un anillo hacia el otro) entre el mostrado en la figura 3 y el mostrado en la figura 4.

La figura 6 ilustra el hardware pertinente usado en un nodo único.

La figura 7 proporciona un detalle adicional de la tarjeta de conmutación y tarjeta de interfaz de anillo en la figura 6.

La figura 8 es un diagrama de flujo que ilustra las etapas usadas para identificar un cambio en el estado de la red y para reencaminar el tráfico a través de la red.

Descripción detallada de las realizaciones

El objetivo de la invención descrita en el presente documento es conseguir una protección rápida en una red de anillo mientras se proporciona una utilización de la capacidad de red eficiente. Ciertos aspectos de la realización preferida son:

a. La transmisión de un paquete dado entre dos nodos en sólo una dirección por el anillo (en vez de en ambas direcciones tal como se realiza en UPSR SONET).

b. La diferenciación entre clases de tráfico "protegido" y "no protegido".

c. Un mecanismo de comunicación de topología rápido para comunicar rápidamente la información sobre una ruptura de tramo a todos los nodos en el anillo.

d. Un mecanismo de actualización de tabla de reencaminamiento/encaminamiento rápido para reencaminar los trayectos afectados por una ruptura de tramo hacia la otra dirección por el anillo.

e. Un mecanismo de desvío intermedio opcional que puede usarse para aumentar adicionalmente la velocidad de conmutación de protección.

Estos aspectos se describen con más detalle a continuación.

Transmisión unidireccional

Un paquete/flujo dado entre dos nodos se transmite sólo en una única dirección por la red (incluso cuando hay un error de tramo) y se retira del anillo por el nodo destino, tal como se muestra en la figura 3 en la que el nodo 0 transmite información hacia el nodo 5 sólo en la dirección indicada mediante las flechas gruesas. Una transmisión desde el nodo 5 hacia el nodo 0 sólo atravesaría los nodos 6 y 7 en la dirección opuesta. Esto permite una utilización de la capacidad de anillo optimizada dado que ninguna capacidad se reserva para la protección.

La ruta física de menor coste se usa normalmente para el tráfico protegido. Ésta es a menudo la ruta física de salto más corto. Por ejemplo, una transmisión desde el nodo 0 hacia el nodo 2 se transmitiría normalmente a través del nodo 1. La ruta física de salto más corto corresponde a la ruta de menor coste cuando las condiciones de tráfico por toda la red son relativamente uniformes. Si las condiciones de tráfico no son uniformes, la ruta física de menor coste desde el nodo 0 hacia el nodo 2 puede ser en su lugar el trayecto largo por el anillo.

La retirada de paquetes desde el anillo por el nodo destino garantiza que el tráfico no use más capacidad que la necesaria para suministrarlo hacia el nodo destino, permitiendo así una capacidad de anillo aumentada mediante la reutilización espacial de la capacidad. Un ejemplo de reutilización espacial es lo siguiente. Si se usa el 20% de la capacidad de tramo para el tráfico que fluye desde el nodo 0 hacia el nodo 2 a través del nodo 1, entonces la retirada de este tráfico desde el anillo en el nodo 2 significa que el 20% de la capacidad de tramo está ahora disponible para cualquier tráfico que fluya en cualquiera de los demás tramos en el anillo (entre los nodos 2 y 3, los nodos 3 y 4, etc.)

Clases de tráfico protegido y no protegido

En el caso de la transmisión unidireccional descrita anteriormente, la pérdida de cualquier tramo en el anillo dará como resultado una reducción en la capacidad de red. Esto resulta del hecho de que el tráfico que fluiría a lo largo de un tramo dado durante las operaciones normales debe compartir la capacidad de otros tramos en el caso de un fallo de ese tramo. Por ejemplo, la figura 4 muestra una ruptura de tramo entre los nodos 6 y 7. A diferencia de la figura 3, una transmisión desde el nodo 0 hacia el nodo 5 debe desplazarse ahora en una dirección horaria en otro anillo (ilustrado mediante las flechas gruesas), añadiéndose al tráfico en ese anillo.

Dado que se pierde cierta capacidad de red en el caso de una interrupción de tramo, una red muy cargada sin capacidad reservada para la protección debe sufrir cierto tipo de degradación del rendimiento como resultado de una interrupción de este tipo. Si el tráfico se clasifica en una clase "protegida" y una clase "no protegida", pueden implementarse un control y provisión de red de modo que el servicio de tráfico protegido no se vea afectado por la interrupción de tramo. En tal caso, toda la degradación del rendimiento es "absorbida" por la clase de tráfico no protegido por medio de una reducción en el ancho de banda promedio, pico y en ráfaga asignado al tráfico no protegido en tramos disponibles restantes de modo que haya suficiente capacidad de red para transportar todo el tráfico protegido. El tráfico dentro de la clase no protegida puede diferenciarse adicionalmente en diversas subclases de modo que ciertas subclases sufren más degradación que otras. Esta degradación puede estar constituida por un retardo adicional o abandono de este tráfico. Los mecanismos para la planificación y gestión de tráfico protegido y no protegido no están cubiertos en esta memoria descriptiva.

Mecanismo de comunicación de topología rápido

Debido a los requisitos de Telcordia mencionados anteriormente, la pérdida de un tramo en un anillo debe detectarse y comunicarse rápidamente a todos los nodos en un anillo.

En el caso de una interrupción de tramo, el nodo en el extremo receptor de cada enlace dentro del tramo detecta que cada enlace individual ha fallado. Si sólo no funciona un único enlace, entonces sólo se notifica la pérdida de ese enlace. Dependiendo de las características de control de rendimiento (PM) soportadas por la pila de protocolos de comunicaciones particular que esté empleándose, esta detección puede basarse en la pérdida de la señal óptica (o eléctrica), la degradación de la tasa de transmisión de errores de bits (BER), la pérdida de trama u otras indicaciones.

Cada interrupción de enlace debe comunicarse entonces a los demás nodos. Esto se realiza de la manera más eficiente a través de un (paquete de) mensaje(s) de radiodifusión (almacenamiento y reenvío), aunque también podría realizarse a través de un mensaje de unidifusión desde el nodo de detección hacia cada uno de los demás nodos en la red. Este mensaje debe enviarse al menos en la dirección opuesta a la que conduce al tramo roto. El mensaje debe contener la información que indique qué enlace ha fallado.

Mecanismo de reencaminamiento de nodo fuente rápido

Cuando un nodo dado reciba un mensaje de interrupción de enlace, el nodo debe tomar medidas para reencaminar el tráfico que pasaba normalmente a través del enlace. Una posible secuencia de acciones es:

a. recibir el mensaje de interrupción de enlace;

b. evaluar todas las posibles rutas físicas internodales (hay 2*(N-1) de ellas en un anillo de N nodos) para determinar cuáles se ven afectadas por la pérdida del enlace;

c. actualizar las tablas de encaminamiento para obligar a todo el tráfico afectado a encaminarse de la otra manera por el anillo; y

d. actualizar la capacidad asignada a las clases de tráfico no protegido para encargarse de la capacidad de red reducida asociada con la interrupción de enlace. Los detalles de cómo se lleva a cabo esta asignación de capacidad no están cubiertos en esta memoria descriptiva.

El hecho de poder realizar las operaciones anteriores rápidamente requiere que las diversas tablas estén organizadas de manera apropiada para permitir rápidamente la identificación de los trayectos afectados. Adicionalmente, las actualizaciones deben basarse en algoritmos simples desde el punto de vista del cálculo o bien en tablas de consulta calculadas previamente.

Mecanismo de desvío intermedio opcional

Para aumentar la velocidad de conmutación de protección, puede ser deseable tomar una acción directa en el/los nodo(s) que detecta(n) el error, en vez de esperar a que el reencaminamiento tenga lugar en todos los nodos. Una posible secuencia de acciones es:

a. tras la detección de un error de enlace de entrada, un nodo debe transmitir un mensaje de notificación de error vecino al nodo en el otro lado del enlace erróneo. Esta notificación sólo es necesaria si hay un único fallo de enlace, ya que el nodo que usa el enlace fallido como enlace de salida no podría detectar que había pasado a ser erróneo. En el caso de que se rompa un tramo completo, el fallo para recibir estas notificaciones no afecta a las siguientes
etapas.

b. Tras la detección de un fallo de enlace de entrada o tras la recepción de un mensaje de notificación de error vecino, un nodo debe desviar el tráfico ligado al enlace de salida correspondiente en ese tramo en el otro anillo. Esto se muestra en la figura 5. El tráfico desde el nodo 0 ligado al nodo 5 se desvía mediante el nodo 7 en el anillo opuesto porque el tramo que conecta el nodo 7 hacia el nodo 6 está roto.

Las etapas anteriores son opcionales y sólo deberían usarse si es necesario un aumento de la velocidad de conmutación de protección al usar este enfoque. Esto se debe a que el desvío del tráfico desde un anillo hacia el otro usa significativamente más capacidad de anillo que el enfoque convencional descrito en este documento. Durante el periodo, aunque corto, entre el inicio del desvío y la finalización del reencaminamiento en los nodos fuente, la capacidad que debe reservarse para la protección es tanta como la necesaria en BLSR de dos fibras.

Algoritmos específicos Mecanismo de comunicación de topología rápido

Esta sección describe un mecanismo rápido específico para comunicar cambios de topología a los nodos en una red de anillo. El mecanismo para comunicar información acerca de una degradación o ruptura de enlace o tramo desde un nodo hacia todos los demás nodos en un anillo es el siguiente.

Un mensaje de estado de enlace se envía desde cada nodo que detecta cualquier degradación o ruptura de enlace en enlaces de entrada hacia el nodo, por ejemplo enlaces para los que el nodo está en el extremo receptor. (Por tanto, para una única ruptura de tramo los dos nodos en los extremos del tramo enviarán cada uno un mensaje de estado de enlace que notifique el fallo de un único enlace de entrada distinto). Este mensaje puede enviarse en la dirección de anillo opuesta a la ruptura de enlace o en ambas direcciones de anillo. Por motivos de robustez, es deseable enviar el mensaje en ambas direcciones de anillo. En una red que no desvía mensajes desde una dirección de anillo hacia la otra dirección de anillo, es necesario que el mensaje se envíe en ambas direcciones de anillo para manejar escenarios de fallos tal como el de la figura 4. El mensaje también puede ser un mensaje de radiodifusión o unidifusión hacia cada nodo en el anillo. Por motivos de robustez y para ahorrar capacidad, es deseable usar radiodifusión. En particular, la radiodifusión garantiza que el conocimiento de la ruptura de enlace alcanzará todos los nodos, incluso aquéllos que son nuevos para el anillo y cuya presencia puede no ser conocida para el nodo que envía el mensaje. En cualquier caso, el mecanismo garantiza que el tiempo de propagación necesario para que el mensaje alcance todos los nodos en el anillo esté limitado por arriba por el tiempo necesario para que un mensaje de máxima prioridad se desplace por toda la circunferencia del anillo. Es deseable que cada mecanismo también garantice que los mensajes que pasan a través de cada nodo se procesan de la manera más rápida posible. Esto minimiza el tiempo para que el mensaje alcance todos los nodos en el anillo.

El mensaje de estado de enlace enviado por un nodo debería contener al menos la siguiente información: dirección de nodo fuente, identificación de enlace del enlace degradado o roto para el que el nodo está en el extremo receptor, y estado de enlace para ese enlace. Por motivos de simplicidad de implementación, puede expandirse el mensaje de estado de enlace para contener estado e identificación de enlace para todos los enlaces para los que el nodo está en el extremo receptor. La identificación de enlace para cada enlace, en general, debería contener al menos la dirección de nodo del nodo en el otro extremo del enlace desde el nodo fuente y el identificador de interfaz física correspondiente de la conexión del enlace al nodo destino. El mecanismo mediante el que el nodo fuente obtiene esta información se encuentra en la solicitud de patente en tramitación junto con la presente titulada "Dual-Mode Virtual Red Addressing," nº de serie __________, presentada junto con la presente por Jason Fan et al., transferida al presente cesionario. El identificador de interfaz física es importante, por ejemplo, en una red de dos nodos en la que la dirección del otro nodo no es suficiente para resolver qué enlace está realmente roto o degradado. El estado de enlace debería indicar el nivel de degradación del enlace, expresado normalmente en términos de tasa de transmisión de errores de bits medida en el enlace (o en caso de que el enlace esté roto, un identificador especial tal como 1).

El mensaje de estado de enlace puede contener opcionalmente dos valores de estado de enlace para cada enlace en caso de que la conmutación de protección sea no reversible. Un ejemplo de conmutación no reversible se ilustra por un enlace que se degrada debido, por ejemplo, a la pérdida temporal de potencia óptica, que luego se recupera. La pérdida de potencia óptica provocaría la conmutación de protección de otros nodos en la red. Sin embargo, la vuelta de potencia óptica no provocaría la conmutación de vuelta de los nodos a rutas por defecto en el caso de una conmutación no reversible hasta que lo ordenara explícitamente un sistema de gestión externo. Por tanto, los dos valores de estado de enlace para cada enlace pueden estar constituidos por un estado que refleje el último estado medido del enlace (previamente descrito) y un estado que refleje el peor estado medido (o mayor coste de enlace) del enlace desde el último momento en el que se determinó el valor por un sistema de gestión externo.

El mensaje de estado de enlace puede confirmarse opcionalmente por los otros nodos. En el caso de que el mensaje no se confirme, debe enviarse múltiples veces para garantizar que lo reciben todos los demás nodos. En el caso de que el mensaje requiera acuse de recibo, debe confirmarse por todos los nodos destinatarios esperados en cierto umbral de tiempo. Si no, el nodo fuente puede elegir reenviar el mensaje de estado de enlace a todos los destinatarios esperados, o reenviar el mensaje de estado de enlace específicamente a los destinatarios esperados que no acusaron recibo del mensaje.

Mecanismo de reencaminamiento de nodo fuente rápido

Esta sección describe un mecanismo que permite a un nodo en una red de anillo reencaminar rápidamente trayectos que cruzan enlaces rotos. Lo siguiente describe un mecanismo de reencaminamiento de nodo fuente rápido cuando el nodo 0 es el nodo fuente.

Para cada nodo destino j, se asigna un coste a cada dirección de salida (0 y 1) desde el nodo 0 en el anillo. Una dirección preferida para el tráfico desde los nodos 0 hacia j se selecciona basándose en la dirección con el menor coste. Por motivos de simplicidad, el mecanismo para reasignar costes al trayecto a cada nodo destino para cada dirección de salida desde el nodo 0 opera con un número constante de operaciones, independientemente de la condición actual del anillo. (El mecanismo puede optimizarse adicionalmente para usar siempre el mínimo número de operaciones posible, aunque esto añadirá complejidad al algoritmo sin aumentar significativamente la velocidad de conmutación de protección total). El mecanismo para reasignar una dirección de salida a paquetes de tráfico destinados para un nodo dado basándose en el coste de trayecto minimiza el tiempo necesario para completar esta reasignación.

Se mantiene una tabla en cada nodo con las columnas nodo destino, coste de dirección 0 y coste de dirección 1. En la tabla 1 se muestra un ejemplo. El cálculo del coste en una dirección desde el nodo 0 (suponiendo que el nodo 0 es la fuente) hacia el nodo j puede tener en cuenta una variedad de factores, incluyendo el número de saltos desde fuente hacia destino en esa dirección, la tasa de transmisión de errores de bits normalizada acumulativa desde fuente hacia destino en esa dirección y el nivel de congestión de tráfico en esa dirección. Basándose en esos costes, puede seleccionarse directamente la dirección preferida de salida para tráfico desde la fuente hacia cualquier destino. El ejemplo dado a continuación supone que los costes corresponden sólo a la tasa de transmisión de errores de bits normalizada desde fuente hacia destino en cada dirección. El coste en un enlace dado se ajusta a 1 si la tasa de transmisión de errores de bits medida es menor que el umbral de tasa de transmisión de errores de bits operacional. De manera conveniente, si todos los enlaces son completamente operacionales, el coste acumulativo desde el nodo 0 hacia el nodo j será igual al número de saltos desde el nodo 0 hacia el nodo j si no hay congestión de tráfico. En este ejemplo no se tiene en cuenta la congestión de tráfico.

Para un anillo representativo con un total de 8 nodos (en orden horario 0, 1, 2, 3, 4, 5, 6, 7), el ajuste operacional normal de la tabla en el nodo 0 es:

TABLA 1 Tabla de dirección preferida en el nodo 0

1

La dirección preferida es aquélla con el menor coste para alcanzar el nodo destino j. En el caso de que los costes para alcanzar el nodo j en la dirección 0 y en la dirección 1 sean iguales, entonces puede seleccionarse cualquier dirección. (En este ejemplo se selecciona la dirección 0). El coste operacional normal para cada ruta física (fuente a destino) se calcula a partir de la tabla de estado de enlace mostrada en la tabla 2.

El pseudocódigo para la selección de la dirección preferida es:

100

101

\vskip1.000000\baselineskip

La tabla de estado de enlace (a la que se ha accedido por una CPU en cada nodo) se usa para calcular los costes en la tabla de dirección preferida anterior. El ajuste operacional normal de la tabla de estado de enlace es:

\vskip1.000000\baselineskip

TABLA 2 Tabla de estado de enlace (idéntica en cada nodo)

2

El coste para cada enlace dij es la tasa de transmisión de errores de bits normalizada, donde la tasa de transmisión de errores de bits medida en cada enlace se divide entre la tasa de transmisión de errores de bits operacional por defecto (normalmente 10E-9 o menor). En el caso de que la tasa de transmisión de errores de bits normalizada sea menor que 1 para un enlace, el valor introducido en la tabla para ese enlace es 1.

El pseudocódigo para la línea "Actualizar coste de dirección 0 y coste de dirección 1" para cada nodo j en el pseudocódigo para la selección de la dirección preferida usa la tabla de estado de enlace mostrada en la tabla 2 de la siguiente manera:

102

103

La actualización de la tabla de estado de enlace se basa en el siguiente pseudocódigo:

104

En el caso de que un enlace esté roto, el linkstatusmessage.status para ese enlace es un valor muy grande. En el caso de que un enlace esté degradado, el linkstatusmessage.status para ese enlace es la tasa de transmisión de errores de bits medida en ese enlace dividido entre la tasa de transmisión de errores de bits no degradada de ese enlace. Se supone que todos los enlaces no degradados tienen la misma tasa de transmisión de errores de bits no
degradada.

La tabla de estado de enlace puede contener opcionalmente dos columnas de coste por dirección para manejar escenarios de conmutación no reversible. Estas serían coste medido (equivalente a las columnas mostradas actualmente en la tabla 2) y coste no reversible. La columna de coste no reversible para cada dirección contiene el mayor valor de coste de enlace notificado desde la última vez que se determinó el valor por un sistema de gestión externo. Esta columna de coste (en lugar del coste medido) se usaría para el cálculo de la dirección preferida en el escenario de conmutación no reversible. La tabla de dirección preferida también puede contener opcionalmente dos columnas de coste por dirección, tal como la tabla de estado de enlace. También puede contener dos columnas de dirección preferida, una basada en los costes medidos y la otra basada en los costes no reversibles. De nuevo, se usarían las columnas de coste no reversible para cálculos en el escenario de conmutación no reversible.

Como ejemplo, supongamos que el enlace en sentido horario entre el nodo 2 y el nodo 3 está degradado por un factor a (en el que a > HYST_FACT), el enlace en sentido horario entre el nodo 4 y el nodo 5 está roto (factor MAX), el enlace en sentido antihorario entre el nodo 1 y el nodo 2 está degradado por un factor b (en el que b > HYST_FACT) y el enlace en sentido antihorario entre el nodo 5 y el nodo 6 está degradado por un factor c (en el que c < a/HYST_FACT). La tabla de estado de enlace para este ejemplo se muestra en la tabla 3.

\vskip1.000000\baselineskip

TABLA 3 Ejemplo de tabla de estado de enlace con enlaces degradados y rotos

4

\vskip1.000000\baselineskip

Los costes de los enlaces necesarios entre el nodo fuente y el nodo destino se suman para determinar el coste total.

\newpage

La tabla de dirección preferida para el nodo fuente 0 es entonces:

TABLA 4 Ejemplo de tabla de dirección preferida con enlaces degradados y rotos

5

(En la selección de la dirección preferida, se supone que HYST_FACT = 10).

Una vez que se determinan estas direcciones preferidas, se modifica una tabla de mapeo correspondiente del nodo destino con la dirección preferida en los procesadores de paquete en el trayecto de datos para corresponder con la tabla anterior.

Notificación de error vecino en mecanismo de desvío intermedio opcional

Esta sección describe un mecanismo rápido específico para la comunicación de una notificación de error desde el nodo en un lado del tramo erróneo hacia el nodo en el otro lado. Este mecanismo, tal como se describió anteriormente, sólo es necesario en el caso de un fallo de enlace único, puesto que el nodo que usa ese enlace como su enlace de salida no puede detectar que es erróneo.

Un mensaje de notificación de error vecino se envía desde cada nodo que detecta cualquier degradación o ruptura de enlace en un enlace de entrada hacia el nodo. El mensaje se envía en cada enlace de salida que forma parte del mismo tramo que el enlace de entrada erróneo. Para garantizar que se recibe, el mensaje de notificación puede confirmarse a través de una transmisión en ambas direcciones por el anillo. Si no se confirma, entonces el nodo de transmisión debe enviar la notificación múltiples veces para garantizar que se recibe. El mensaje es de máxima prioridad para garantizar que se minimiza el tiempo requerido para recibir el mensaje en el destino.

El mensaje de notificación de error vecino enviado por un nodo debería contener al menos la siguiente información: dirección de nodo fuente, identificación de enlace del enlace degradado o roto para el que el nodo está en el extremo receptor y estado de enlace para ese enlace. Por motivos de simplicidad de implementación, el mensaje de notificación de error vecino puede ser equivalente al mensaje de estado de enlace emitido a todos los nodos que se ha descrito anteriormente.

Descripción de hardware

La figura 6 ilustra los bloques funcionales pertinentes en cada nodo. El nodo 0 se muestra como ejemplo. Cada nodo está conectado a nodos adyacentes por tarjetas 30 y 32 de interfaz de anillo. Estas tarjetas de interfaz de anillo convierten las señales ópticas entrantes en cables 34 y 36 ópticos de fibra óptica en señales digitales eléctricas para su aplicación a la tarjeta 38 de conmutación.

La figura 7 ilustra una tarjeta 32 de interfaz de anillo con más detalle que muestra el transceptor 40 óptico. Puede usarse un conmutador adicional en la tarjeta 32 para conmutar entre dos tarjetas de conmutación para añadir fiabilidad. El transceptor óptico puede ser un transceptor óptico Gigabit Ethernet que use un láser de 1300 nm, comercialmente disponible.

La salida en serie del transceptor 40 óptico se convierte en un grupo paralelo de bits mediante un serializador/deserializador (SERDES) 42 (figura 6). El SERDES 42, en un ejemplo, convierte una serie de 10 bits desde el transceptor 40 óptico en un grupo paralelo de 8 bits usando una tabla. Los códigos de 10 bits seleccionados para corresponder con códigos de 8 bits cumplen con criterios de compensación en el número de 1 y 0 por código y el número máximo de 1 y 0 consecutivos para un rendimiento mejorado. Por ejemplo, un gran número de 1 lógicos secuenciales crea fluctuación lenta de fase de referencia, un desplazamiento en el nivel de tensión promedio a largo plazo usado por el receptor como umbral para diferenciar entre 1 y 0. Utilizando una palabra de 10 bits con un número compensado de 1 y 0 en el plano posterior, se reduce considerablemente la fluctuación lenta de fase de referencia, permitiendo así un mejor acoplamiento de CA de las tarjetas al plano posterior.

Cuando el SERDES 42 recibe datos de 10 bits en serie desde la tarjeta 32 de interfaz de anillo, el SERDES 42 puede detectar si hay un error en la palabra de 10 bits si la palabra no coincide con una de las palabras en la tabla. El SERDES 42 genera entonces una señal de error. El SERDES 42 usa la tabla para convertir el código de 8 bits desde la tarjeta 38 de conmutación en un flujo en serie de 10 bits para su procesamiento adicional por la tarjeta 32 de interfaz de anillo. El SERDES 42 puede ser un modelo VSC 7216 de Vitesse o cualquier otro tipo adecuado.

Un controlador 44 de acceso al medio (MAC) cuenta el número de errores detectados por el SERDES 42, y estos errores se transmiten a la CPU 46 durante una interrupción o según un mecanismo de interrogación. La CPU 46 puede ser un microprocesador Motorola MPC860DT. Después se describirá lo que ocurre cuando la CPU 46 determina que el enlace se ha degradado lo suficiente para llevar a cabo una acción para hacer que los nodos reencaminen el tráfico para evitar el enlace erróneo. El MAC 44 también retira cualquier palabra de control reenviada por el SERDES y proporciona formateo (de enlace de datos) de capa 2 OSI para un protocolo particular estructurando una trama MAC. Los MAC se conocen bien y se describen en el libro "Telecommunication System Engineering" de Roger Freeman, tercera edición, John Wiley & Sons, Inc., 1996. El MAC 44 puede ser una disposición de puertas de campo programable.

El procesador 48 de paquetes asocia cada uno de los bits transmitidos por el MAC 44 con un campo de paquetes, tal como el campo de cabecera o el campo de datos. El procesador 48 de paquetes detecta entonces el campo de cabecera del paquete estructurado por el MAC 44 y puede modificar información en la cabecera para paquetes no destinados para el nodo. Ejemplos de procesadores 48 de paquetes adecuados incluyen el XPIF-300 Gigabit Bitstream Processor o el EPIF 4-L3C1 Ethernet Port L3 Processor de MMC Networks.

El procesador 48 de paquetes intercomunica con una máquina de búsqueda externa/memoria 47 (una tabla de consulta) que contiene información de encaminamiento para encaminar los datos hacia su destino previsto. La actualización de la tabla de encaminamiento en la memoria 47 se tratará con detalle más tarde.

Una memoria 49 en la figura 6 representa todas las demás memorias en el nodo, aunque debería entenderse que puede haber distribuidas SSRAM, SDRAM, memoria flash y EEPROM para proporcionar los requisitos funcionales y de velocidad necesarios del sistema.

El procesador 48 de paquetes proporciona el paquete a un puerto de la matriz 50 de conmutación, que a continuación encamina el paquete hacia el puerto apropiado de la matriz 50 de conmutación basándose en la cabecera de paquete. Si la dirección de destino en la cabecera de paquete corresponde a la dirección del nodo 0 (el nodo mostrado en la figura 6), la matriz 50 de conmutación encamina entonces el paquete hacia el puerto apropiado de la matriz 50 de conmutación para su recepción por la tarjeta 52 de unión de afluentes de nodo 0 designada (figura 5) (que se tratará con detalle posteriormente). Si la cabecera de paquete indica una dirección diferente que hacia el nodo 0, la matriz 50 de conmutación encamina el paquete a través de la tarjeta 30 ó 32 de interfaz de anillo apropiada (figura 5). Los paquetes de control se encaminan hacia la CPU 46. Se conocen bien las matrices de conmutación y las técnicas de encaminamiento de este tipo usadas para determinar el trayecto que necesitan adoptar los paquetes a través de las matrices de conmutación y no es necesario describirlas con detalle.

Un conmutador de paquetes adecuado es el modelo nP5400 Packet Conmutador Module de MMC Networks. En una realización, cuatro conmutadores de este tipo están conectados en cada tarjeta de conmutación para un rendimiento más rápido. Los conmutadores proporcionan capacidad de radiodifusión y multidifusión, almacenamiento en memoria intermedia de paquetes, cuatro clases de prioridad de servicio y planificación basándose en una puesta en cola justa ponderada o de prioridad estricta.

Un procesador 54 de paquetes asociado con una o más tarjetas de unión de afluentes, por ejemplo, la tarjeta 52 de unión de afluentes, recibe un paquete desde la matriz 50 de conmutación destinada al equipo (por ejemplo, una LAN) asociado con la tarjeta 52 de unión de afluentes. El procesador 54 de paquetes es bidireccional, tal como el procesador 48 de paquetes. Los procesadores 54 y 48 de paquetes pueden ser los mismos procesadores modelo. Generalmente, el procesador 54 de paquetes detecta la dirección de los datos a través del procesador 54 de paquetes y accede a una memoria 55 de tabla de encaminamiento para determinar algunos de los campos de cabecera deseados y el trayecto de encaminamiento óptimo para los paquetes dirigidos hacia el anillo, y el trayecto deseado a través del conmutador para paquetes dirigidos hacia o fuera del anillo. Esto se trata con más detalle posteriormente. Cuando el procesador 54 de paquetes recibe un paquete desde la matriz 50 de conmutación, reenvía el paquete a una unidad 56 de control de acceso al medio (MAC), que realiza una función similar a la del MAC 44, que a continuación reenvía el paquete al SERDES 58 para serializar los datos. El SERDES 58 es similar al SERDES 42.

La salida del SERDES 58 se aplica entonces a una tarjeta de unión de afluentes particular, tal como la tarjeta 52 de unión de afluentes en la figura 5, conectada a un plano 59 posterior. La tarjeta de unión de afluentes puede poner los datos en cola y encaminar los datos hacia un puerto de salida particular de la tarjeta 52 de unión de afluentes. Tal encaminamiento y puesta en cola por las tarjetas de unión de afluentes pueden ser convencionales y no es necesario describirlos con más detalle. Las salidas de las tarjetas de unión de afluentes pueden estar conectadas eléctricamente, tal como a través de un cable de cobre, a cualquier tipo de equipo, tal como un conmutador de teléfono, un encaminador, una LAN u otro equipo. Las tarjetas de unión de afluentes también pueden convertir señales eléctricas en señales ópticas mediante el uso de transceptores ópticos, en caso de que la interfaz externa sea óptica.

El controlador 62 de sistema obtiene información de estado desde el nodo e intercomunica con un sistema de gestión de red. Este aspecto del nodo no es pertinente para la invención. El controlador de sistema puede estar programado para notificar diversas pruebas de la red.

En una realización, el hardware descrito anteriormente procesa bits a una tasa de transmisión superior a 1 Gbps.

Funciones de hardware durante el error/degradación de tramo

La figura 8 es un diagrama de flujo que resume las acciones realizadas por hardware de red durante un error o degradación de tramo. Puesto que se conocen bien el hardware y las técnicas de encaminamiento convencionales, esta explicación se centrará en las características novedosas de la realización preferida.

En la etapa 1 de la figura 8, cada uno de los nodos comprueba constante o periódicamente sus enlaces con nodos vecinos. El MAC 44 en la figura 7 cuenta errores en el flujo de datos (tal como se describió anteriormente) y comunica estos errores a la CPU 46. La CPU compara la tasa de transmisión de errores de bits con un umbral predeterminado para determinar si el enlace es satisfactorio. Un fallo de enlace óptico también puede comunicarse a la CPU. La CPU 46 puede controlar enlaces de entrada desde dispositivos adyacentes basándose en el recuento de errores mediante el MAC 44 o basándose en la detección de una pérdida de potencia óptica en la fibra 36 de entrada. Esta detección se realiza mediante una variedad de transceptores ópticos comercialmente disponibles tales como la familia de transceptores Lucent NetLight. La pérdida de condición de potencia óptica puede notificarse a la CPU 46 a través de señalización directa por el plano posterior (tal como a través de las líneas I2C), dando lugar a un evento de nivel bajo o interrupción en la CPU.

En la etapa 2, la CPU 46 determina si hay un cambio en el estado del enlace adyacente. Este cambio en el estado puede ser un error (tasa de transmisión de errores de bits que supera el umbral) o que se ha reparado un enlace previamente erróneo. Se supondrá para este ejemplo que el nodo 6 detectó un error en el enlace de entrada que lo conecta al nodo 7.

Si no hay detección de un error en la etapa 2, no se realiza ningún cambio de la red. Se supone en la figura 8 que ambos nodos 6 y 7 adyacentes detectan errores en enlaces de entrada que conectan el nodo 6 al nodo 7. La detección de un error lleva a un evento de nivel bajo o interrupción (generado por el MAC 44) enviado a través de la matriz 50 de conmutación a la CPU 46 que indica el cambio en el estado.

En la etapa 3 opcional, los nodos 6 y 7 intentan notificar uno a otro directamente el error de enlace de entrada detectado por cada uno. La notificación enviada por el nodo 6, por ejemplo, se envía en el enlace de salida del nodo 6 conectado al nodo 7. Si está roto todo el tramo, evidentemente estas notificaciones no alcanzan el destino. Sólo son útiles si está roto un único enlace dentro de un tramo. Esto se debe a que un nodo no tiene forma de detectar una ruptura de fibra que afecte a un enlace de salida. Basándose en esta notificación, cada nodo puede desviar entonces el tráfico directamente de la manera mostrada en la figura 5. El desvío del tráfico en el nodo 6 se realiza a través de una orden de configuración desde la CPU 46 hacia el procesador 48 de paquetes conectado tal como se muestra en la figura 7 hacia la tarjeta 32 de interfaz de anillo (suponiendo que los enlaces desde la tarjeta 32 de interfaz de anillo se conectan al nodo 7). Después de recibir esta orden, el procesador 48 de paquetes devuelve el tráfico a través de la matriz de conmutación y fuera de la tarjeta 30 de interfaz de anillo que normalmente lo enviaría directamente al nodo 7.

Cada comunicación mediante un nodo de estado de enlace está asociada con un número de sesión. Se genera un número de sesión nuevo mediante un nodo sólo cuando detecta un cambio en el estado de un nodo vecino. Siempre que los nodos reciban paquetes con el número de sesión actual, entonces los nodos saben que no hay ningún cambio en la red. Ambos nodos 6 y 7 incrementan el número de sesión almacenado en cada nodo tras la detección de un error en cada nodo.

En la etapa 4, tanto el nodo 6 como el nodo 7 emiten entonces un mensaje de estado de enlace, incluyendo el número de sesión nuevo, que transporta la ubicación del error a todos los nodos. Cada nodo, que detecta el número de sesión nuevo, reenvía la emisión a su nodo adyacente.

Una descripción adicional del uso del número de sesión en escenarios de reconfiguración de topología generales, de los que un fallo de tramo o enlace es uno, se encuentra en la solicitud de patente en tramitación junto con la presente titulada "Dual-Mode Virtual Network Addressing", de Jason Fan et al. transferida al presente cesionario.

En la etapa 5, la identidad del error se usa entonces por el procesador 54 de paquetes en cada nodo para actualizar la tabla de encaminamiento en la memoria 55. En general se conocen bien las tablas de encaminamiento y asocian una dirección de destino en una cabecera con un nodo físico particular al que encaminar los datos asociados con la cabecera. Cada tabla de encaminamiento se configura entonces para minimizar el coste desde un nodo fuente hacia un nodo destino. Normalmente, si el trayecto previamente optimizado hacia un nodo destino hubiera tenido que ir a través del enlace erróneo, entonces se actualiza esa ruta para transmitirse a través de la dirección inversa a través del anillo para evitar la ruta errónea. Se cambiaría la tabla de encaminamiento para cada uno de los procesadores 54 de paquetes en cada nodo según fuera necesario dependiendo de la posición del nodo con respecto al enlace erróneo. Previamente se describieron los detalles de las tablas de encaminamiento.

En una realización, cada uno de los nodos debe confirmar la emisión con el número de sesión nuevo, y el nodo de origen sigue la pista de los acuses de recibo. Después de haber superado un límite de tiempo sin recibir todos los acuses de recibo, vuelve a emitirse la ubicación del error sin incrementar el número de secuencia.

Por consiguiente, todos los nodos almacenan la topología actual del anillo, y todos los nodos pueden crear independientemente las entradas óptimas de la tabla de encaminamiento para la configuración actual del anillo.

En la etapa 6, se ha actualizado la tabla de encaminamiento para cada nodo y se ha reanudado el tráfico de datos. Por consiguiente, los datos que se originan desde una LAN conectada a una tarjeta 52 de unión de afluentes (figura 5) tienen añadida a los mismos una cabecera de encaminamiento actualizada por el procesador 54 de paquetes para encaminar los datos a través de la matriz 50 de conmutación hacia el puerto de salida apropiado para permitir que los datos lleguen a su destino previsto. El destino puede ser el mismo nodo que originó los datos y, por tanto, la matriz 50 de conmutación desviaría los datos de vuelta a través de una tarjeta de unión de afluentes en el mismo nodo. Puede usarse cualquier técnica de encaminamiento puesto que la invención puede aplicarse en general a cualquier técnica de encaminamiento y protocolo.

Puesto que debe reencaminarse cierto tráfico por el anillo para evitar el enlace erróneo, y los anchos de banda de los enlaces son fijos, el tráfico que va a transmitirse por los enlaces sin errores puede superar el ancho de banda de los enlaces sin errores. Por consiguiente, puede ser necesario abandonar o retardar cierto tráfico de prioridad menor, tal como se identifica en la etapa 7. En general, el tráfico clasificado como "no protegido" se abandona o retarda según sea necesario para soportar el tráfico "protegido" debido al ancho de banda reducido.

En una realización, el procesador 54 de paquetes detecta la cabecera que identifica los datos como no protegidos y abandona el paquete, según sea necesario, antes de aplicar el paquete a la matriz 50 de conmutación. En general el tráfico de voz está protegido.

En la etapa 8, la matriz 50 de conmutación encamina cualquier paquete reenviado por el procesador 54 de paquetes hacia el puerto de salida apropiado para su transmisión de vuelta al nodo o bien a un nodo adyacente.

La descripción anterior del hardware usado para implementar una realización de la invención es suficiente para un experto en la técnica para fabricar la invención puesto que el hardware general para encaminamiento y conmutación de paquetes se conoce muy bien. Un experto en la técnica podría programar fácilmente los MAC, los procesadores de paquetes, la CPU 46 y demás unidades funcionales para llevar a cabo las etapas descritas en el presente documento. Puede usarse firmware o software para implementar las etapas descritas en el presente documento.

Aunque se han mostrado y descrito realizaciones particulares de la presente invención, resultará evidente para los expertos en la técnica que pueden realizarse cambios y modificaciones sin apartarse de esta invención en sus aspectos más amplios.

Claims (43)

1. Un conmutador de encaminamiento para su uso en una red de comunicaciones en la que una pluralidad de conmutadores de encaminamiento están interconectados por enlaces de comunicación en un primer anillo y un segundo anillo, conmutador de encaminamiento que comprende:

uno o más transceptores (30, 32) que pueden conectarse a enlaces (34, 36) de comunicación asociados para su conexión a uno o más conmutadores de encaminamiento adyacentes en dicha red;

una tabla (47) de encaminamiento;

una matriz (50) de conmutación dispuesta para encaminar tráfico hacia y desde dichos uno o más transceptores (30, 32) basándose en la tabla (47) de encaminamiento, y

uno o más procesadores (46) adaptados para:

\quad

comprobar la calidad de dichos enlaces de comunicación entre dichos uno o más conmutadores de encaminamiento adyacentes;

\quad

detectar si uno o más primeros enlaces de dichos enlaces de comunicación no cumplen con un umbral de calidad;

\quad

transmitir información que identifica dichos uno o más primeros enlaces desde el conmutador de encaminamiento hacia otros conmutadores de encaminamiento en dicha red;

\quad

corregir dicha tabla (47) de encaminamiento para reencaminar el tráfico afectado, de modo que el tráfico afectado no atraviese dichos uno o más primeros enlaces debido a que dichos uno o más primeros enlaces son erróneos; y

\quad

encaminar tal tráfico afectado hacia un nodo destino, basándose en dicha tabla de encaminamiento corregida, en una dirección por dicho anillo diferente de una dirección con la que se habría desplazado hacia dicho nodo destino en caso de que dichos uno o más primeros enlaces no hubieran sido erróneos;

\quad

caracterizado porque:

la matriz (50) de conmutación está dispuesta para encaminar tráfico hacia y desde dichos uno o más transceptores (30, 32) de modo que durante la operación normal el tráfico fluye hacia otros conmutadores de encaminamiento en dicha red tanto por el primer anillo como el segundo anillo; y

el procesador (46) está dispuesto para corregir dicha tabla (47) de encaminamiento para crear un trayecto de reencaminamiento teniendo en cuenta un número de saltos para el tráfico entre un conmutador fuente y uno destino en dicho trayecto de reencaminamiento, una tasa de transmisión de errores de bits normalizada acumulativa desde el conmutador fuente y el destino en dicho trayecto de reencaminamiento y un nivel de congestión de tráfico entre el conmutador fuente y el destino en dicho trayecto de reencaminamiento.

2. El conmutador de encaminamiento según la reivindicación 1, en el que dichos uno o más procesadores (46) incluyen una CPU conectada a la matriz (50) de conmutación.

3. El conmutador de encaminamiento según la reivindicación 1 o la reivindicación 2, en el que el uno o más procesadores (46) están dispuestos para controlar el conmutador de encaminamiento para transmitir y recibir periódicamente mensajes de comprobación hacia y desde conmutadores de encaminamiento vecinos en dicha red y detectar la calidad de los enlaces que transportan tales mensajes de comprobación.

4. El conmutador de encaminamiento según la reivindicación 3, en el que el uno o más procesadores (46) están dispuestos para controlar el conmutador de encaminamiento para detectar la calidad de dichos enlaces basándose en comparar una tasa de transmisión de errores de bits con un umbral.

5. El conmutador de encaminamiento según la reivindicación 3, en el que el uno o más procesadores (46) están dispuestos para controlar el conmutador de encaminamiento para detectar la calidad de dichos enlaces detectando una pérdida de una señal óptica.

6. El conmutador de encaminamiento según la reivindicación 3, en el que el uno o más procesadores (46) están dispuestos para controlar el conmutador de encaminamiento para detectar la calidad de dichos enlaces detectando una pérdida de una señal eléctrica.

7. El conmutador de encaminamiento según la reivindicación 3, en el que el uno o más procesadores (46) están dispuestos para controlar el conmutador de encaminamiento para detectar la calidad de dichos enlaces detectando una pérdida de una trama.

8. El conmutador de encaminamiento según la reivindicación 1 o la reivindicación 2, en el que el uno o más procesadores (46) están dispuestos para controlar el conmutador de encaminamiento para recibir mensajes desde otros conmutadores de encaminamiento en dicha red que identifican un enlace erróneo y corregir la tabla (47) de encaminamiento para reencaminar el tráfico.

9. El conmutador de encaminamiento según la reivindicación 1 o la reivindicación 2, en el que el uno o más procesadores (46) están dispuestos para controlar el conmutador de encaminamiento para transmitir periódicamente mensajes de estado de enlace junto con un número de sesión, crear un número de sesión nuevo cuando se ha detectado que dichos uno o más primeros enlaces no cumplen con dicho umbral de calidad y transmitir la identidad de cualquier enlace erróneo junto con dicho número de sesión nuevo hacia otros conmutadores de encaminamiento en dicho anillo.

10. El conmutador de encaminamiento según la reivindicación 9, en el que el uno o más procesadores (46) están dispuestos para controlar el conmutador de encaminamiento para comparar un número de sesión transmitido con un número de sesión almacenado y, si el número de sesión es diferente, corregir la tabla (47) de encaminamiento para tener en cuenta un enlace erróneo.

11. El conmutador de encaminamiento según la reivindicación 10, en el que el uno o más procesadores (46) están dispuestos para controlar el conmutador de encaminamiento para corregir dicha tabla de encaminamiento para identificar rutas óptimas para destino de tráfico.

12. El conmutador de encaminamiento según cualquier reivindicación anterior, en el que el uno o más procesadores (46) están dispuestos para controlar el conmutador de encaminamiento para añadir una cabecera de encaminamiento a un mensaje que va a enviarse a dicho nodo destino.

13. El conmutador de encaminamiento según cualquier reivindicación anterior, en el que dicho tráfico comprende paquetes.

14. El conmutador de encaminamiento según cualquiera de las reivindicaciones 1 a 12, en el que dicho tráfico comprende células.

15. El conmutador de encaminamiento según cualquier reivindicación anterior, en el que el uno o más procesadores (46) están dispuestos para controlar el conmutador de encaminamiento para abandonar ciertos tipos de tráfico debido a un ancho de banda reducido en dicha red cuando dichos uno o más primeros enlaces son erróneos.

16. El conmutador de encaminamiento según cualquier reivindicación anterior, en el que el uno o más procesadores (46) están dispuestos para controlar el conmutador de encaminamiento para desviar el tráfico de llegada dirigido a un conmutador de encaminamiento con un enlace erróneo por una dirección diferente en dicha red.

17. El conmutador de encaminamiento según cualquier reivindicación anterior, en el que el uno o más procesadores (46) están dispuestos para controlar el conmutador de encaminamiento para requerir un acuse de recibo por dichos otros conmutadores de encaminamiento de que se ha recibido un mensaje de estado de enlace y, si no se ha recibido dicho acuse de recibo, retransmitir dicho mensaje de estado.

18. El conmutador de encaminamiento según cualquier reivindicación anterior, dispuesto para procesar tráfico a una tasa de transmisión superior a 1 gigabit por segundo.

19. El conmutador de encaminamiento según la reivindicación 1, en el que el uno o más procesadores (46) están dispuestos para controlar el conmutador de encaminamiento para detectar si uno o más primeros enlaces, cuando están conectados al mismo, cumplen con un umbral de calidad, después de no cumplir con dicho umbral de calidad, y transmitir información hacia otros conmutadores de encaminamiento para identificar que dichos uno o más primeros enlaces ahora cumplen con dicho umbral de calidad.

20. Un procedimiento realizado por una red de comunicaciones en la que los nodos están interconectados por enlaces de comunicación en un primer anillo y un segundo anillo, procedimiento que comprende:

comprobar (1) automáticamente la calidad de los enlaces de comunicación entre nodos;

detectar (2) mediante un primer nodo si uno o más primeros enlaces no cumplen con un umbral de calidad;

transmitir (3) información desde dicho primer nodo hacia otros nodos para identificar dichos uno o más primeros enlaces;

corregir (5) una tabla (47) de encaminamiento en al menos algunos de dichos nodos para reencaminar el tráfico afectado de modo que el tráfico reencaminado no atraviese dichos uno o más primeros enlaces, debido a que dichos uno o más primeros enlaces son erróneos; y

encaminar el tráfico por un nodo fuente hacia un nodo destino, basándose en una tabla (47) de encaminamiento corregida en el nodo fuente, para encaminar el tráfico en una dirección por la red diferente de una dirección con la que se habría desplazado el tráfico hacia el nodo destino en caso de que dichos uno o más primeros enlaces no hubieran sido erróneos;

caracterizado porque:

\quad

dicha tabla (47) de encaminamiento se corrige para crear un trayecto de reencaminamiento teniendo en cuenta un número de saltos para el tráfico entre un conmutador fuente y uno destino en dicho trayecto de reencaminamiento, una tasa de transmisión de errores de bits normalizada acumulativa desde el conmutador fuente y el destino en dicho trayecto de reencaminamiento y un nivel de congestión de tráfico entre el conmutador fuente y el destino en dicho trayecto de reencaminamiento.

21. El procedimiento según la reivindicación 20, en el que el tráfico comprende información en un formato según un protocolo.

22. El procedimiento según la reivindicación 21, en el que la información está en forma de paquetes.

23. El procedimiento según la reivindicación 21, en el que la información está en forma de tramas.

24. El procedimiento según la reivindicación 21, en el que la información está en forma de células.

25. El procedimiento según cualquiera de las reivindicaciones 20 a 24, en el que a un estado de un enlace se le asigna un valor de calidad, y en el que la etapa de transmisión comprende:

cargar el valor de calidad por el primer nodo para indicar un cambio en el estado del enlace debido a la detección por dicho primer nodo de que el enlace no cumple con dicho umbral de calidad; y

transmitir la información para identificar dicho enlace así como un valor de calidad cambiado.

26. El procedimiento según la reivindicación 25, que incluye las etapas de:

recibir por los nodos en la red una señal transmitida desde dicho primer nodo, incluyendo la señal transmitida dicho valor de calidad cambiado; y en respuesta,

corregir una tabla (47) de encaminamiento en al menos algunos de dichos nodos para reencaminar el tráfico para tener en cuenta dichos uno o más primeros enlaces que son erróneos.

27. El procedimiento según la reivindicación 26, en el que la tabla (47) de encaminamiento no se corrige si dicho valor de calidad es el mismo que un valor de calidad previo.

28. El procedimiento según cualquiera de las reivindicaciones 20 a 27, que incluye las etapas de:

designar una primera clase de tráfico para que tenga una mayor prioridad que una segunda clase de tráfico; y

reducir la capacidad asignada a la segunda clase de tráfico si hay una reducción de ancho de banda de la red debido a dicha corrección de la tabla (47) de encaminamiento.

29. El procedimiento según cualquiera de las reivindicaciones 20 a 28, que incluye la etapa de retirar de la red el tráfico designado para ser recibido por un nodo destino tras la recepción de dicho tráfico por dicho nodo destino.

30. El procedimiento según cualquiera de las reivindicaciones 20 a 29, en el que el primer anillo de enlaces comunica en una primera dirección por la red y el segundo anillo de enlaces comunica en la dirección opuesta por la red, comprendiendo el procedimiento además:

encaminar el tráfico desde un nodo fuente en el primer anillo en una dirección horaria hacia uno o más nodos destino; y

encaminar el tráfico por el nodo fuente en el segundo anillo en una dirección antihoraria hacia uno o más nodos destino,

y en el que el tráfico generado por un nodo fuente destinado para un único nodo destino se transmite en sólo una dirección por dicha red dependiendo de una ubicación relativa del nodo fuente con respecto al único nodo destino.

31. El procedimiento según cualquiera de las reivindicaciones 20 a 30, en el que la etapa de comprobar automáticamente la calidad de enlaces entre nodos comprende:

enviar una dirección desde un nodo fuente hacia un nodo adyacente por un enlace y detectar la calidad del enlace entre el nodo fuente y dicho nodo adyacente.

32. El procedimiento según la reivindicación 31, en el que la detección de la calidad de dicho enlace entre el nodo fuente y dicho nodo adyacente comprende detectar una tasa de transmisión de errores de bits.

33. El procedimiento según la reivindicación 31, en el que la detección de la calidad de dicho enlace entre el nodo fuente y dicho nodo adyacente comprende detectar si se ha recibido dicha dirección.

34. El procedimiento según la reivindicación 31, en el que la detección de la calidad de dicho enlace entre dicho nodo fuente y dicho nodo adyacente comprende detectar una pérdida de potencia óptica por un receptor óptico en dicho nodo.

35. El procedimiento según cualquiera de las reivindicaciones 20 a 34, en el que la corrección de dicha tabla (47) de encaminamiento comprende:

determinar qué rutas entre nodos están afectadas por dichos uno o más enlaces que son erróneos; y

corregir la tabla (47) de encaminamiento para obligar a todo el tráfico afectado a encaminarse en una dirección opuesta por dicho anillo.

36. El procedimiento según la reivindicación 35, en el que la corrección de dicha tabla (47) de encaminamiento se realiza usando un algoritmo.

37. El procedimiento según la reivindicación 35, en el que la corrección de dicha tabla (47) de encaminamiento usa tablas de consulta previamente calculadas.

38. El procedimiento según cualquiera de las reivindicaciones 20 a 37, en el que la transmisión por el primer nodo comprende además:

transmitir por dicho primer nodo hacia otros nodos en la red tras identificar que uno o más primeros enlaces no cumplen con dicho umbral de calidad, una dirección de nodo fuente de dicho primer nodo y una identificación de los uno o más enlaces erróneos.

39. El procedimiento según la reivindicación 38, en el que la identificación de uno o más primeros enlaces que no cumplen con dicho umbral de calidad incluye una dirección de nodo de los nodos en el otro extremo de un enlace erróneo desde el primer nodo.

40. El procedimiento según la reivindicación 38, en el que la identificación de uno o más enlaces erróneos incluye identificar una interfaz física que identifica la conexión de un enlace erróneo al primer nodo.

41. El procedimiento según la reivindicación 38, en el que la transmisión comprende además comunicar un estado de enlace que incluye el nivel de degradación del uno o más enlaces erróneos.

42. El procedimiento según la reivindicación 41, en el que el nivel de degradación identifica un estado basándose en una tasa de transmisión de errores de bits medida.

43. El procedimiento según cualquiera de las reivindicaciones 20 a 42, en el que el uno o más primeros enlaces que no cumplen con un umbral de calidad lo hacen debido a un fallo de nodo.