Método y dispositivo para recuperarse después de una falla de puente raíz.
Método para notificar puentes (100) conectados a una red (10) de una falla de puente raíz (R0),
que comprendelas siguientes etapas:
(a) detectar, mediante por lo menos un puente (100) conectado directamente al puente raíz (R0), una falla en una conexión al puente raíz (RO);
caracterizado porque el método comprende adicionalmente las etapas de:(b) generar, mediante por lo menos un puente (100) conectado directamente al puente raíz (R0), una notificación desospecha de falla de raíz, RFSN, unidad de datos de protocolo de puente, BPDU, (230) que comprende una porciónBPDU de Árbol de Expansión Rápida estándar (RST) (220) y una porción de identificador de raíz fallida (210) queidentifica únicamente el puente raíz (R0) que se sospecha falla; y
(c) propagar la BPDU RFSN (230) a los puentes adyacentes (100) en la red (10).
Tipo: Patente Europea. Resumen de patente/invención. Número de Solicitud: E10175574.
Solicitante: Ruggedcom Inc.
Nacionalidad solicitante: Canadá.
Dirección: 300 Applewood Crescent, Unit 1 Concord, Ontario L4K 5C7 CANADA.
Inventor/es: PUSTYLNIK,MICHAEL.
Fecha de Publicación: .
Clasificación Internacional de Patentes:
- H04L12/46 ELECTRICIDAD. › H04 TECNICA DE LAS COMUNICACIONES ELECTRICAS. › H04L TRANSMISION DE INFORMACION DIGITAL, p. ej. COMUNICACION TELEGRAFICA (disposiciones comunes a las comunicaciones telegráficas y telefónicas H04M). › H04L 12/00 Redes de datos de conmutación (interconexión o transferencia de información o de otras señales entre memorias, dispositivos de entrada/salida o unidades de tratamiento G06F 13/00). › Interconexión de redes.
PDF original: ES-2399974_T3.pdf
Fragmento de la descripción:
Método y dispositivo para recuperarse después de una falla de puente raíz
Campo de la invención Esta invención se relaciona con el campo de los protocolos de configuración de red utilizados para configurar automáticamente una red arbitraria o en malla en una topología libre de bucles o sin malla que tiene una raíz. Más particularmente, esta invención se relaciona con una mejora en los protocolos de configuración de red, tales como elProtocolo de Árbol de Expansión Rápido (RSTP) para superar una falla del puente raíz en una topología configurada y reducir el tiempo de configuración a una nueva topología libre de bucles en el evento de falla del puente raíz original o un cambio en la topología física tal como un retiro intencional o no intencional del puente raíz desde una topología libre de bucles configurada.
Antecedentes de la invención En el pasado se han conocido redes de ordenadores responsables de reenvío de tramas de datos a estaciones finales. Las redes de ordenadores se pueden organizar en redes de área local con puentes que permiten las comunicaciones entre estaciones finales unidas a LAN separadas, solo como si las estaciones se unieran a la misma LAN. Un puente, tal como un puente, es normalmente un ordenador con una pluralidad de puertos que acoplan el puente a otras entidades. La función de ubicación de puentes incluye recibir datos de uno de los puertos y transferir los datos a otros puertos para ser recibidos por otras entidades en la red. El puente es capaz de mover tramas de datos desde un puerto al otro puerto muy rápido en razón a que su decisión se basa generalmente en la información de la estación final, tal como la información de dirección de control de acceso de medio (MAC pos sus siglas en inglés) contenida en el encabezado de dichas tramas. Los puentes normalmente utilizan una serie de protocolos potenciales para el movimiento de datos como se establece en los estándares de la industria. Uno de dichos estándares es el IEEE 802.1D - 2004 titulado “IEEE Standard for Local y Metropolitan Area Networks Media Access Control (MAC) Bridges” publicado el 3 de junio de 2004 por el IEEE y que se incorpora aquí como referencia. En la actualidad también están disponibles otros protocolos y en el futuro pueden ser posibles.
Cuando se forma una red de ordenador, la red tendrá generalmente una ruta de comunicación redundante y usualmente aleatoria entre cada uno de los puentes. Esto surge a partir de diversos puentes en las redes que tienen sus puertos conectados a otros puentes en la red en una forma redundante. Adicionalmente, se pueden agregar o retirar puentes periódicamente a la red existente. Adicionalmente, los puentes pueden fallar durante la operación de la red. Este es particularmente el caso si se utilizan puentes en entornos adversos, tales como se pueden encontrar en aplicaciones industriales y/o estaciones de generación energía y/o otros entornos adversos. Adicionalmente, las conexiones de red entre los puentes pueden fallar por una serie de razones. En general, son deseables rutas redundantes en la red con el fin de mejorar la robustez de la red y evitar la falla de la misma sin una conexión específica cualquiera entre los dos puentes falla o falla el puente completo. De esta forma, se pueden utilizar rutas redundantes, en donde dos rutas diferentes conectan los mismos puentes, para superar fallas de enlace y fallas de puente en la red.
Sin embargo, las rutas redundantes aumentan la ambigüedad en la red. En otras palabras, si existe la posibilidad de que se forme una ruta de circuito o “bucle” en la red, de tal manera que una trama pueda viajar en el bucle continuamente y nunca alcance el usuario final para el que está destinada la trama. Por lo tanto la creación de un bucle en una red de puente aumenta la posibilidad de que las tramas de datos atraviesen continuamente el bucle sin alcanzar el usuario final hasta que se satura la red. La creación de bucles en una red puente también aumenta las ambigüedades en la tabla de direcciones dentro de cada puente específico reduciendo la eficiencia de la red.
Para permitir la existencia de rutas de comunicación redundantes, pero para evitar problemas de formación de bucles, en el pasado se han propuesto diversos métodos de “podar” una red en una configuración de árbol o libre debucles. Uno de dichos protocolos es el Protocolo y Algoritmo de Árbol de Expansión Rápido (“RSTP”) por sus siglas en inglés descrito en el estándar IEEE 802.1D - 2004. En el pasado se han propuesto diversos protocolos, talescomo el “Protocolo y Algoritmo de Árbol de Expansión” o STP pero ahora se han sustituido por el “Protocolo y Algoritmo de Árbol Expansión Rápido” (RSTP por sus siglas en inglés) . Una característica común de estos protocolos es que la topología resultante tiene una raíz o puente raíz desde la cual se extiende sucesivamente la topología libre de bucle en una forma libre de bucle no redundante.
Sin embargo, surgen dificultades en estos tipos de protocolos cuando falla el puente raíz. Estos tipos de fallas, conocidas como “fallas de puente raíz” son particularmente problemáticas debido a que diversos puentes dentro de la red continuaran imponiendo el puente raíz con falla como la raíz actúa incluso si ellos reciben información en contrario de otros puentes en la red. Por lo tanto, recuperarse de una falla de puente raíz puede ser más problemático y tiene un mayor tiempo de reconfiguración que la configuración original del protocolo de árbol de expansión ya que en la configuración original ninguno de los puentes tiene un valor predeterminado que identifique que el puente es el puente raíz actual.
El problema surge, en parte, porque cuando falla un puente raíz, los otros puentes identifican la falla del puente raíz anterior imponiéndolo asincrónicamente como el nuevo puente raíz, pero los puentes que no están advertidos de la falla de puente raíz continuarán imponiendo el puente raíz original. En una realización, para obtener información necesaria para correr un protocolo de árbol de expansión, los puentes intercambiarán mensajes de configuración especiales, denominados frecuentemente unidades de datos de protocolo de puente (BPDU) . Más específicamente, luego del inicio de la red, cada puente asume inicialmente que el mismo es el puente raíz y transmite los BPDU que reflejan esto. Luego de la falla del puente raíz, los puentes adyacentes al puente raíz original asumirán inicialmente que son la nueva raíz y transmitirán los BPDU que reflejan esta presunción. Luego de la recepción de un BPDU desde un dispositivo vecino, el puente examinará los contenidos del BPDU y si el puente raíz identificado en el BPDU recibido es “mejor”, con base en criterios predeterminados, el identificador de nodo raíz almacenado en el puente de recepción, el puente adopta la mejor información y la utiliza en su propio BPDU que la envía a otros puentes desde sus puertos.
Aunque este proceso funciona bien al comienzo el puente raíz original falla, algunos de los puentes en la red pueden continuar enviando BPDU que identifican el puente raíz original, ahora fallido. Esto surge por una serie de factores. Por ejemplo, cada puente será advertido de la falla potencial del puente raíz original y envía asincrónicamente BPDU que se imponen como el nuevo puente raíz. Adicionalmente, en redes grandes, algunos puentes ubicados remotamente del puente raíz pueden no estar advertidos de la falla del puente raíz y pueden reimponer el identificador de puente raíz del puente de raíz original ahora fallido. Es importante observar que el identificador de puente raíz del puente raíz fallido será la “mejor” selección por lo que el puente raíz original, ahora fallido se selecciona como el puente raíz en la configuración original.
Este puede aumentar el tiempo mediante el cual se puede crear una convergencia a una nueva topología libre de bucles después de la falla de un puente raíz. Adicionalmente, mientras la información de puente raíz original eventualmente se agotará, esto puede no ocurrir para una cantidad significativa de tiempo, tal como unos pocos segundos, ya que los puentes estarán recibiendo periódicamente información de algunos de los otros puentes en a red que identifican el puente raíz viejo, ahora fallido, como a un activo, incluso cuando la información no sea correcta sino desactualizada. Dicho problema ha sido denominado eufemísticamente como “conteo hasta el infinito” que se refiere al proceso sin fin mediante el cual no se identifica la falla de un puente raíz mediante todos los puentes en una red y se notificarán continuamente entre sí a través... [Seguir leyendo]
Reivindicaciones:
1. Método para notificar puentes (100) conectados a una red (10) de una falla de puente raíz (R0) , que comprende las siguientes etapas:
(a) detectar, mediante por lo menos un puente (100) conectado directamente al puente raíz (R0) , una falla en una conexión al puente raíz (RO) ;
caracterizado porque el método comprende adicionalmente las etapas de:
(b) generar, mediante por lo menos un puente (100) conectado directamente al puente raíz (R0) , una notificación de sospecha de falla de raíz, RFSN, unidad de datos de protocolo de puente, BPDU, (230) que comprende una porciónBPDU de Árbol de Expansión Rápida estándar (RST) (220) y una porción de identificador de raíz fallida (210) que identifica únicamente el puente raíz (R0) que se sospecha falla; y
(c) propagar la BPDU RFSN (230) a los puentes adyacentes (100) en la red (10) .
2. Método de acuerdo con la reivindicación 1, que comprende adicionalmente las etapas:
(d) luego de recepción de la BPDU RFSN (230) mediante un puente de recepción (100) en la red (10) , que compara el identificador de raíz fallido recibido (210) en la BPDU RFSN (230) con un identificador de raíz almacenado (104) almacenado en el puente de recepción (100) ; y
(e) si el puente raíz (100) identificado en la porción de identificador de raíz fallida (210) corresponde al identificador de raíz almacenado (104) , eliminar el identificador de raíz almacenado (104) en el puente de recepción (100) .
3. Método de acuerdo con la reivindicación 2, que comprende adicionalmente las etapas:
(f) cada puente (100) que recibe una BPDU RFSN (230) que actúa sobre la porción BPDU estándar (220) de la BPDU RFSN (230) ya sea o no el que identificador de raíz fallido recibido (210) corresponde al identificador de raíz almacenado (104) ; y
(g) propagar la BPDU RFSN (230) a otros puentes (100) en la red (10) para repetir las etapas (d) a (g) .
4. Método de acuerdo con la reivindicación 2, que comprende adicionalmente las etapas: cuando se genera la BPDU RFSN (230) , configurar un indicador de identificador de raíz fallido, FRD (222) en la porción BPDU RST estándar (220) ; y luego de recepción de la BPDU RFSN (230) por el puente de recepción (100) , verificar el indicador FRI (222) y, si se configura, comparar la porción recibida de identificador de raíz fallida (210) al identificador de raíz almacenado (104) en el puente de recepción (100) .
5. Método de acuerdo con la reivindicación 4, en donde para los puentes (100) en la red (10) que carecen de lacapacidad de identificar la BPDU RFSN (230) utilizando el Protocolo y Algoritmo de Árbol de Expansión Rápida, RSTP, ignorar la porción de identificador de raíz fallida (210) y propagar la porción BPDU estándar (220) sin la porción de identificador de raíz fallida (210) .
6. Método de acuerdo con la reivindicación 4, en donde el indicador FRI (222) corresponde al indicador reconocido de cambio de topología (223) codificado en el Bit 8 del Octeto 5 en la porción BPDU RST estándar (220) .
7. Método de acuerdo con una cualquiera de las reivindicaciones 2 a 6, en donde la etapa de generar la BPDU RFSN (230) mediante por lo menos un puente (100) conectado directamente al puente raíz (R0) comprende adicionalmente:
comprimir la porción de identificador de raíz fallida (210) de tal manera que la BPDU RFSN (230) consiste de no más de 60 bytes; y luego de recepción de la BPDU RFSN (230) por el puente de recepción (100) , descomprimir el identificador de raíz fallido comprimido (212) para obtener el identificador de puente (210) que identifica únicamente el puente raíz (R0) que se sospecha falla.
8. Método de acuerdo con la reivindicación 7, donde la red (10) es una red Ethernet; y en donde cada BPDU RFSN
(230) está contenida dentro una única trama de datos Ethernet 60 bytes (232) .
9. Método de acuerdo con una cualquiera de las reivindicaciones 2 a 8, que comprende adicionalmente la etapa:
Después de propagar la BPDU RFSN (230) , comenzar un tiempo de de espera para un periodo predeterminado durante el cual el puente de recepción (100) ignorará la porción de identificador de raíz fallida (210) de cualquier BPDU RFSN (230) recibido posteriormente y no eliminará el identificador de raíz almacenado (104) pero actuará sobre la porción BPDU estándar (220) y propagar la porción BPDU estándar (220) sin la porción de identificador de raíz fallida (210) .
10. Método de acuerdo con la reivindicación 1, en los donde puentes (100) de una red (10) de puentes interconectados de acuerdo con una topología activa establecida por un Protocolo y Algoritmo de Árbol de Expansión Rápida, RSTP, dicha topología activa que comprende una topología libre de bucles original que emana de un puente raíz original (R0) , se notifican de una falla de puente raíz, en donde en la etapa (a) , una falla en el puente raíz original (R0) se detecta en un puente (100) conectado directamente al puente raíz original (R0) en la topología libre de bucles original;
en la etapa (b) , una notificación de sospecha de falla de raíz, RFSN, unidad de datos de protocolo de puente, BPDU,
(230) que comprende una porción BPDU estándar (220) y una porción de identificador de raíz fallida (210) que identifica únicamente el puente raíz original (R0) se genera en el puente (100) conectado directamente al puente raíz original (R0) ; y
en la etapa (c) , la BPDU RFSN (230) se propaga por el puente (100) conectado directamente al puente raíz original (R0) a los puentes adyacentes (100) para notificar los puentes adyacentes (100) de una sospecha de que el puente raíz original (R0) ha fallado y proporcionar información BPDU estándar en la porción BPDU estándar (220) como si el puente raíz original (R0) hubiera fallado para comenzar la convergencia hacia una nueva topología libre de bucles con un nuevo puente raíz (R1) diferente del puente raíz original (R0) .
11. Método de acuerdo con la reivindicación 10, que comprende adicionalmente las etapas:
(d) luego de recepción de la BPDU RFSN (230) por un puente de recepción (100) en la red (10) , comparar, en el puente de recepción (100) , la porción de identificador de raíz fallida recibida (210) que identifica el puente raíz original (R0) a un identificador de raíz almacenado (104) almacenado en el puente de recepción (100) , y,
(e) si corresponden, eliminar, en el puente de recepción (100) , el identificador de raíz almacenado (104) .
12. Método de acuerdo con la reivindicación 11, que comprende adicionalmente las etapas:
(f) cada puente que recibe una BPDU RFSN (230) que actúa sobre la porción BPDU estándar (220) de la BPDU RFSN (230) ya sea o no que el identificador de raíz fallido recibido (210) corresponde al identificador de raíz almacenado (104) ; y
(g) propagar la BPDU RFSN (230) a otros puentes (100) en la red (10) para repetir las etapas (d) a (f) .
13. Método de acuerdo con la reivindicación 12, que comprende adicionalmente las etapas:
cuando se genera la BPDU RFSN (230) , configurar un indicador de identificador de raíz fallido, FRD (222) en la porción BPDU RST estándar (220) ; y luego de recepción de la BPDU RFSN (230) por el puente de recepción (100) , verificar el indicador FRI (222) y, si se configura, comparar la porción recibida de identificador de raíz fallida (210) con el identificador de raíz almacenado (104) en el puente de recepción (100) ; y en donde, para los puentes (100) en la red (10) que carecen de la capacidad para identificar la BPDU RFSN (230) utilizando Protocolo y Algoritmo deÁrbol de Expansión Rápida, RFSD, ignorar la porción de identificador de raíz fallida (210) y propagar la porción BPDU estándar (220) sin la porción de identificador de raíz fallida (210) .
14. Método de acuerdo con la reivindicación 11, en donde la etapa para generar la BPDU RFSN (230) por el puente
(100) conectado directamente al puente raíz original (R0) en la topología libre de bucles original comprende adicionalmente las etapas de:
comprimir la porción de identificador de raíz fallida (210) de tal manera que la BPDU RFSN (230) consiste de no más de 60 bytes; y
luego de recepción de la BPDU RFSN (230) por el puente de recepción (100) , descomprimir el identificador de raíz fallido comprimido (212) para obtener el identificador de (210) que identifica únicamente el puente raíz (R0) que se sospecha falla; y
en donde la red (10) es una red Ethernet, y, cada BPDU RFSN (230) está contenida en una única trama de datos de 60 bytes (232) .
15. Método de acuerdo con una cualquiera de las reivindicaciones 11 a 14, que comprende adicionalmente la etapa de:
después de propagar la BPDU RFSN (230) , comenzar un tiempo de de espera para un periodo predeterminado durante el cual el puente (100) ignorará la porción de identificador de raíz fallida (210) de cualquier BPDU RFSN 5 (230) recibida posteriormente y no eliminará el identificador de raíz almacenado (104) pero actuará sobre la porción BPDU estándar (220) y propagará la porción BPDU estándar (220) sin la porción de identificador de raíz fallida (210) .
16. Un puente (100) para notificar otros puentes (100) conectados a una red (10) de una falla de puente raíz (R0) , dicho puente (100) comprende medios para ejecutar todas las etapas del método de una cualquiera de las reivindicaciones 1 a 15.
17. Un programa de ordenador que comprende instrucciones que, cuando se ejecutan por uno o más procesadores de un puente (100) , provocan que el puente (100) ejecute todas las etapas del método descrito en una cualquiera de las reivindicaciones 1 a 15.
EL PUENTE DIRECTAMENTE CONECTADO AL PUENTE RAÍZ DETECTA LA FALLA SOBRE EL ENLACE AL PUENTE RAÍZ
EL PUENTE DIRECTAMENTE CONECTADO AL PUENTE RAÍZ GENERA Y ENVÍA BPDU RFSN CON IDENTIFICADOR DE PUENTE RAÍZ FALLIDO COMPRIMIDO
BDPU ESTÁNDAR (SIN IDENTIFICADOR DE PUENTE RAÍZ FALLIDO COMPRIMIDO) SE RECIBEN Y PROPAGAN PERO EL TIEMPO DE ESPERA SE COMIENZA PARA EL PERIODO PREDETERMINADO DURANTE EL CUAL NINGÚN BPDU RFSN POSTERIOR SE ACCIONA EN O SE PROPAGA
Tabla 1
Tiempo de recuperación de falla de raíz R0 a nueva raíz R1 en ms para topología de malla 501
sin BPDU RFSN permitidas
ENSAYO
y solo las con BPDU BPDU estándar RFSN de la permitidas técnica anterior
Promedio
Tabla 2
Tiempo de recuperación de falla de raíz R0 a
nueva raíz R1 en ms para
topología de malla 502
sin BPDU
ENSAYO con BPDU RFSN permitidas y solo las BPDU
RFSN estándar de la
permitidas técnica anterior
Promedio Tabla 3 Tiempo de recuperación de falla de raíz R0 a nueva raíz R1 en ms para topología de malla 503 sin BPDU RFSN ENSAYO permitidas con y solo las BPDU BPDU RFSN
estándar de permitidas la técnica anterior
Promedio Tabla 4 Tiempo de recuperación de falla de raíz R0 a nueva raíz R1 en ms para topología de malla 504
sin BPDU
RFSN
ENSAYO con BPDU permitidasy solo las BPDU estándar de la
RFSN técnica
permitidas anterior
Promedio Tabla 5 Tiempo de recuperación de falla deraíz R0 a nueva raíz R1 en ms para topología de malla 505
sin BPDU
RFSN
ENSAYO con permitidasy solo las BPDU
BPDU RFSN permitidas estándar de la técnica anterior
Promedio
Tabla 6
Tiempo de recuperación de falla de raíz R0 a nueva raíz R1 en ms para topología de malla 506
sin BPDU RFSN permitidas ENSAYO y solo las BPDU
con estándar BPDU de la RFSN técnica permitidas anterior
Promedio
Patentes similares o relacionadas:
Sistemas y métodos para proporcionar una arquitectura de enlace seguro múltiple, del 1 de Julio de 2020, de E^NAT Technologies, LLC: Un sistema para proporcionar una arquitectura de enlace seguro múltiple, MSL, comprendiendo dicho sistema: un componente de red privada virtual, […]
Método para la gestión mejorada de llamadas de emergencia en un escenario de itinerancia y sistema, programa informático y medio legible por ordenador correspondientes, del 17 de Junio de 2020, de DEUTSCHE TELEKOM AG: Un método para la gestión mejorada de llamadas de emergencia en un escenario de itinerancia, en donde un equipo de usuario se asigna a una red de telecomunicaciones […]
Protocolos de control de sistema de chasis virtual, del 3 de Junio de 2020, de ALCATEL LUCENT: Un nodo de red (110a-110f) adaptado para ser parte de un sistema de chasis virtual que tiene una pluralidad de nodos de red dispuestos de modo que la pluralidad de […]
Método para establecer relaciones entre conjuntos de rutas de etiquetas conmutadas y redes virtuales, del 3 de Junio de 2020, de HUAWEI TECHNOLOGIES CO., LTD.: Un método para establecer un túnel de extremo a extremo que se extiende a través de múltiples dominios utilizando un elemento de red, que comprende: asociar […]
Dispositivo de bus de campo para comunicarse con un dispositivo de automatización remoto, del 27 de Mayo de 2020, de DEUTSCHE TELEKOM AG: Dispositivo de bus de campo para comunicarse con un dispositivo de automatización remoto (FI) a través de una red de comunicación , donde […]
Método para implementar un túnel de GRE, un punto de acceso y una puerta de enlace, del 22 de Abril de 2020, de HUAWEI TECHNOLOGIES CO., LTD.: Un método para implementar un túnel de encapsulamiento de enrutamiento genérico, GRE, que comprende: enviar , por un punto de acceso, […]
Sistemas y métodos para detección automática de dispositivo, gestión de dispositivo y asistencia remota, del 15 de Abril de 2020, de Bitdefender IPR Management Ltd: Un regulador [18] de red conectado a múltiples sistemas cliente [12a-f] en una red [14] local, en donde un enrutador [19] provee un servicio de red que comprende asignar direcciones […]
Sistema y método para establecer una conexión entre un primer dispositivo electrónico y un segundo dispositivo electrónico, del 1 de Abril de 2020, de ALE INTERNATIONAL: Un método implementado por ordenador para establecer una conexión de paquetes entre una primera aplicación que se ejecuta en un primer dispositivo electrónico […]