PROCEDIMIENTO DE REPARACIÓN AGRUPADA DE CAMINOS EN FALLO Y PUENTE DE RED.

La presente invención describe un procedimiento de reparación agrupada de caminos en fallo y puente de red que permite,

en una red de puentes transparentes con aprendizaje de direcciones de origen del tipo conocido como All-Path, la reparación agrupada de los caminos utilizados por un enlace cuando éste falla mediante una trama de difusión, emitida por los dos puentes conectados a los extremos del enlace en fallo, la cual transporta la lista de direcciones de destino asociadas al enlace antes del fallo. Esta petición de reparación se realiza mediante un mensaje de difusión dirigido a la dirección de grupo multicast común a todos los puentes All-Path y con un identificador de protocolo All-Path. Los puentes frontera conectados a terminales que precisan reparación responden al mensaje enviando un mensaje unicast de reparación (o un ARP Reply convencional) hacia el puente que originó el mensaje, restaurando así los caminos hacia cada terminal.

Tipo: Patente de Invención. Resumen de patente/invención. Número de Solicitud: P201331139.

Solicitante: UNIVERSIDAD DE ALCALA..

Nacionalidad solicitante: España.

Inventor/es: ROJAS SÁNCHEZ,Elisa, IBÁÑEZ FERNÁNDEZ,Guillermo, CARRAL FERNÁNDEZ,Juan Antonio.

Fecha de Publicación: .

Clasificación Internacional de Patentes:

  • H04L12/24 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). › Disposiciones para el mantenimiento o la gestión.
PROCEDIMIENTO DE REPARACIÓN AGRUPADA DE CAMINOS EN FALLO Y PUENTE DE RED.

Fragmento de la descripción:

PROCEDIMIENTO DE REPARACIÓN AGRUPADA DE CAMINOS EN FALLO Y

PUENTE DE RED

SECTOR DE LA TÉCNICA

La presente invención se encuadra dentro del sector de las comunicaciones y de los dispositivos electrónicos y/o aplicaciones informáticas que establecen las comunicaciones entre puentes transparentes.

ESTADO DE LA TÉCNICA

Son conocidos protocolos de establecimiento de caminos denominados Fast-Path y All- Path [G. Ibáñez, J. A. Carral, A. Garcia-Martinez, J. M. Arco, D. Rivera, and A. Azcorra, "Fast Path Ethernet Switching: On-demand, Efficient Transparent Bridges for Data Center and Campus Networks", 17° IEEE Workshop on Local and Metropolitan Area Networks (LANMAN), New Jersey, USA, May 2010] [G. Ibáñez, J.A. Carral, J.M. Arco, D. Rivera, and A. Montalvo. ARP-Path: ARP-Based, Shortest Path Bridges. IEEE Communications Letters, 2011, pp.770-772] que establecen caminos mediante la exploración simultánea de toda la red mediante una trama de difusión como el ARP Request y una trama unicast ARP Reply y el aprendizaje en los puentes atravesados de las direcciones MAC origen y su asociación al puerto por donde se recibe primero la trama difundida.

Estos protocolos presentan el inconveniente de que cuando cae un enlace o un puente es necesario reparar individualmente bajo demanda cada camino existente en dicho enlace cuando va a ser utilizado, lo cual requiere distribuir a toda la red (y procesar de manera especial en los puentes) una trama de difusión de reparación por cada uno de los caminos que se precisa reparar, lo que supone una carga de proceso significativa para los puentes, en particular cuando el número de conexiones activas simultáneamente en un enlace es muy elevado, como es el caso de los enlaces Ethernet de alta capacidad como 1 Gigabit/s y 10 Gigabit/s Ethernet.

Asimismo son conocidos protocolos que asocian bajo ciertas condiciones la dirección MAC origen de tramas unicast a un puerto de entrada y verifican cuando reciben una trama

unicast o broadcast si el puerto está asociado o no a dicha trama [Minkenberg et al. US2011/0032825A1. Multipath discovery in switched Ethernet networks. Fecha de publicación, 10 de febrero de 2011] [Tanaka et al. First arrival port learning method, relay apparatus, and Computer product. US 7760667 B2] [Mack-Crane et al. Media access control bridging in a mesh network. US 2010/0272108 A1], Estos protocolos, cuando el puente no dispone de ruta hacia el destino, es decir, cuando se recibe una trama unicast y la dirección destino no está asociada a ningún puerto del puente, reenvían la trama unicast replicada por todos los puertos excepto por el que se recibió. Esto genera un tráfico adicional en los puentes hasta que las direcciones son aprendidas. Por otra parte estas tramas replicadas deben ser descartadas en los puentes que las reciben para lo que debe comprobarse que son copias mediante alguna verificación.

DESCRIPCIÓN DE LA INVENCIÓN

Breve descripción de la invención

La presente invención describe mecanismos que permiten, en una red de puentes transparentes con aprendizaje de direcciones origen del tipo conocido como All-Path (también denominados FastPath y ARP-Path) la reparación agrupada de todos los caminos utilizados por un enlace cuando éste falla, de forma que, mediante una única trama de difusión se informa a toda la red con la lista de direcciones de destino en fallo y que por tanto precisan que su camino sea reparado.

Los puentes FastPath/AII-Path/ARP-Path solamente aprenden las direcciones origen de las tramas ARP Request, ARP Reply y de otras tramas de control que reciben, bloqueando el aprendizaje de dichas direcciones en otros puertos del puente durante un tiempo suficiente y descartando las tramas de igual origen recibidas durante ese período de bloqueo en otros puertos del puente.

Esta reparación se realiza de forma conjunta y proactiva cuando se detecta el fallo del enlace, enviando en la trama de reparación conjunta todas (o parte de) las direcciones de los terminales (hosts) asociados al puerto de salida del enlace cuando éste falló, mediante un mensaje de difusión dirigido a la dirección de grupo multicast común a todos los puentes All-Path y con un identificador de protocolo All-Path, mensaje que es reenviado a todos los

puentes de la red y procesado en cada uno de los puentes All-Path, el cual es respondido con la emisión de un mensaje unicast desde cada puente frontera del terminal (host) correspondiente a una o varias direcciones a reparar, dirigido al puente intermedio que originó el mensaje de difusión y conectado al enlace en fallo, mensaje que, al atravesar cada puente produce el aprendizaje en dicho puente de la dirección del terminal destino. Este mensaje unicast puede ser un mensaje especial UnicastPathReply o un mensaje estándar ARP Reply.

Descripción detallada de la invención

En una red de seis puentes con caminos establecidos entre los terminales A y B por un lado y los terminales A y C por otro, las direcciones de los terminales A, B y C son aprendidas y asociadas en las tablas de los puentes a los respectivos puertos por donde pasa el camino.

Cuando cae el enlace que une los puentes 2 y 5 ambos puentes anuncian, mediante una trama de difusión LinkFail un mensaje con las direcciones destino que precisan reparación. El puente 2 anunciará en su trama LinkFail las direcciones de los terminales B y C, y el puente 5 anunciará la A. Estos mensajes son de difusión y alcanzan los puentes frontera de los terminales A, B y C. Esta trama de difusión se emite con la dirección MAC origen del puente emisor (2 y 5 respectivamente). Como referencia, en los puentes estándar IEEE 802.1D, se suele utilizar como dirección MAC del puente la del puerto que tiene una dirección MAC de magnitud inferior.

La trama LinkFail se retransmite por todos los puertos de todos los puentes excepto el puerto que la recibe, descartándose las tramas duplicadas recibidas después de la primera, como en el protocolo All-Path. Para ello, durante esa propagación se aprenden las direcciones de los puentes 2 y 5 en la tabla (Learnt Table, LT) de aprendizaje, utilizada para prevención de bucles con un temporizador suficientemente largo, creándose así dos árboles de confluencia con raíces respectivamente en los puentes 2 y 5, los cuales persistirán durante el temporizador de aprendizaje, dejando almacenados temporalmente caminos hacia los puentes 2 y 5 en toda la red.

Los puentes frontera de los terminales A, B y C (1, 6 y 3 respectivamente) contestan enviando una trama en unicast (UnicastPathReply) a los puentes 2 y 5, según corresponda. Cada puente que recibe esa respuesta unicast aprende el camino hacia dichos sistemas A, B y C. La trama unicast UnicastPathReply sólo se propaga desde el puente frontera hasta el puente intermedio (2/5), no de extremo a extremo. Otra realización de esta invención utiliza un paquete ARP Reply como respuesta al paquete LinkFail, en lugar de dicho UnicastPathReply. El puente frontera genera un paquete ARP Reply con dirección origen el terminal (A, B, C) en reparación y como destino el puente intermedio conectado al enlace en fallo (puente 2 o 5).

Si un mensaje UnicastPathReply conteniendo la dirección del terminal A llega a un puente que ya tiene aprendida esa dirección asociada a otro puerto, se elimina la anterior asociación y se actualiza al nuevo puerto de llegada.

Aunque los caminos se recuperan desde el puente frontera hasta el puente inicial que emitió el LinkFail, las tramas de datos en su trayecto por la red pueden encontrar atajos y utilizarlos. Las direcciones aprendidas pero no utilizadas caducarán y permanecerá el camino optimizado y utilizado.

Al finalizar el proceso quedan reparados los caminos en fallo, los cuales evitan el uso del enlace en fallo entre los puentes 2 y 5.

Algunas entradas de tabla quedan obsoletas, como por ejemplo la entrada C en el puente 5 y se eliminan por vencimiento de su temporizador.

En el caso de fallo o apagado de un puente completo, este fallo se detectará en los puentes vecinos como fallo del enlace conectado al puente en fallo, y será procesado por cada uno de los puertos de los puentes conectados al puente en fallo. Cada puente vecino emitirá un LinkFail de forma igual a la descrita, en difusión, conteniendo las direcciones destino de los terminales cuyos caminos hay que reparar estableciendo nuevos caminos desde el puente frontera de cada terminal. Por lo tanto se generarán tantas tramas LinkFail como puertos tiene conectados el puente en fallo a otros puentes con enlaces activos.

En una realización alternativa de esta invención, la trama UnicastPathReply se sustituye por una trama BroadcastPathReply que se emite desde el puente frontera por...

 


Reivindicaciones:

1. Procedimiento de reparación agrupada de caminos de tramas de datos que comprende:

- recibir, a través de un puerto de un puente de red donde dicho puerto tiene una identidad de puerto asignada, una trama que comprende una dirección MAC origen y una dirección MAC destino;

- asociar, en una unidad de registro, la dirección MAC origen de la trama recibida a la identidad del puerto del puente que primero recibió la trama, a un indicador de caducidad de la trama y al instante de llegada de la trama;

- borrar, en la unidad de registro, las asociaciones que tenga un puerto de un puente cuando detecte la caída de un enlace en dicho puerto o expire el temporizador de validez de la dirección;

caracterizado porque cuando se detecta la caída de un enlace en dicho puerto el procedimiento comprende:

- enviar una trama especial de reparación agrupada (LinkFail) conteniendo parte o todas las direcciones MAC asociadas al puerto del enlace en fallo, con dirección MAC origen la del puente que la emite y dirección de destino de difusión;

- incluir en un registro de direcciones en reparación la lista de direcciones MAC asociadas a dicho enlace;

- descartar las sucesivas tramas recibidas unidestino cuya dirección MAC destino exista en un registro de direcciones en proceso de reparación;

- establecer un tiempo de guarda que bloquea la modificación de la asociación dirección MAC origen-puerto de entrada y la creación de nuevas asociaciones de dicha dirección MAC a otros puertos del mismo puente.

2. Procedimiento de reparación agrupada de caminos de tramas de datos según la reivindicación 1, caracterizado porque en los puentes donde se recibe la trama especial de reparación agrupada, se comprueba si alguna de las direcciones MAC contenidas corresponde a un terminal directamente conectado al puente (puente frontera del terminal) o conectado a través de un puente estándar IEEE 802.1D:

- En caso afirmativo: enviar una trama unicast de reparación con dirección origen la del terminal y dirección destino la del puente que emitió la trama de difusión, con identificador del protocolo All-Path (transportado en el campo Ethertype si se utiliza formato de trama Ethernet nativa DIX o en la dirección SSAP/DSAP, si se utiliza encapsulado LLC).

- En todos los casos: aprender en cada puente que recibe dicha trama especial unicast de reparación su dirección origen, asociándola en exclusiva al puerto que la recibe, reparando así el camino hacia el puente destino que la originó, incluso si la dirección origen está asociada previamente a un puerto distinto del puente.

3. Procedimiento de reparación agrupada de caminos de tramas de datos, según cualquiera de las reivindicaciones anteriores, caracterizado porque las tramas de reparación de camino se seleccionan entre:

- tramas estándar ARP Request y ARP Reply generadas por el terminal correspondiente o por un puente intermedio;

- paquetes especiales de reparación agrupada: LinkFail, UnicastPathReply;

- paquetes especiales de reparación agrupada: LinkFail, BroadcastPathReply;

- combinaciones de los anteriores.

4. Procedimiento de reparación agrupada de caminos de tramas de datos, según cualquiera de las reivindicaciones anteriores, caracterizado porque el registro de direcciones en proceso de reparación comprende las direcciones MAC destino en proceso de reparación y un temporizador de reparación con valor inicial superior al tiempo necesario para que las tramas de reparación recorran la red y sean respondidas.

5. Procedimiento de reparación agrupada de caminos de tramas de datos, según cualquiera de las reivindicaciones anteriores, caracterizado porque al recibir, un puente de red, una trama de reparación agrupada LinkFail:

- Comprobar en su información de estado si alguno de sus puertos activos está conectado directamente a uno o varios terminales activos o conectado indirectamente a través de un puente estándar 802.1D, es decir, tiene aprendidas direcciones MAC en ese puerto pero no recibe mensajes Hello de otros puentes All-

Path por ese puerto, y:

En caso negativo: reenviar la trama de reparación LinkFail por todos los enlaces menos por el que la recibió.

En caso afirmativo:

o inspeccionar la lista de direcciones MAC destino del paquete LinkFail , para las direcciones MAC destino que estén asociadas válidamente a uno de sus puertos en su unidad de registro, y o enviar, hacia atrás por el puerto donde se recibió, una trama UnicastPathReply unidestino con dirección MAC origen la MAC a reparar contenida dentro de la trama recibida y con dirección MAC destino la MAC origen de la trama recibida.

6. Procedimiento de reparación agrupada de caminos de tramas de datos, según cualquiera de las reivindicaciones anteriores, caracterizado porque al recibir, un puente de red, una trama de reparación UnicastPathReply:

- asociar, en cada puente que recibe la trama UnicastPathReply, la dirección MAC origen de la misma al puerto por donde se recibe la trama;

- reenviar, cada puente que recibe la trama UnicastPathReply, la trama recibida, por el puerto asociado a la dirección MAC destino de la trama recibida hasta alcanzar el puente conectado al enlace en fallo;

- anotar, el puente cuya MAC coincida con la MAC destino de la trama UnicastPathReply, la MAC origen de la trama recibida al puerto del puente por el que se recibió la trama y borrarla de la tabla de direcciones en reparación;

- renovar, en cada puente que reenvía la trama, el temporizador asociado a la dirección MAC destino.

7. Procedimiento de reparación agrupada de caminos de tramas de datos, según cualquiera de las reivindicaciones anteriores, caracterizado porque al recibir, un puente de red, un paquete ARP Reply:

- asociar, en cada puente que recibe el paquete ARP Reply, la dirección MAC origen de la misma al puerto por donde se recibe la trama;

- reenviar, cada puente que recibe el paquete ARP Reply, por el puerto asociado a la

dirección MAC destino de la trama recibida hasta alcanzar el puente conectado al enlace en fallo;

- anotar, el puente cuya MAC coincida con la MAC destino del paquete ARP Reply, la MAC origen de la trama recibida al puerto del puente por el que se recibió la trama y borrarla de la tabla de direcciones en reparación;

- renovar, en cada puente que reenvía la trama, el temporizador asociado a la dirección MAC destino.

8. Puente de red que comprende unos medios de procesamiento configurados para:

- recibir, a través de un puerto de un puente de red donde dicho puerto tiene una identidad de puerto asignada, una trama que comprende una dirección MAC origen y una dirección MAC destino;

- asociar, en una unidad de registro, la dirección MAC origen de la trama recibida a la identidad del puerto del puente que primero recibió la trama, a un indicador de caducidad de la trama y al instante de llegada de la trama;

- renovar el temporizador de caducidad de direcciones de la dirección MAC destino por un nuevo periodo a fin de mantener el camino unidireccional a destino activado;

- borrar, en la unidad de registro, las asociaciones que tenga un puerto de un puente cuando detecte la caída de un enlace en dicho puerto o expire el temporizador de validez de la dirección;

caracterizado por que cuando la trama recibida no tiene asociada su dirección MAC destino a ningún puerto en la unidad de registro del puente y hay un puerto, en la unidad de registro del puente que recibe la trama, que esté asociado a la dirección MAC origen de la trama recibida, los medios de procesamiento configurados para:

- descartar las sucesivas tramas recibidas unidestino cuya dirección MAC destino exista en un registro de direcciones en proceso de reparación.

9. Puente de red, según la reivindicación 8 caracterizado porque las tramas de reparación de camino se seleccionan entre:

- tramas estándar ARP Request y ARP Reply generadas por el terminal o por un puente intermedio;

- paquetes especiales de reparación: LinkFail, UnicastPathReply;

- paquetes especiales de reparación agrupada: LinkFail, BroadcastPathReaply- combinaciones de las anteriores.

10. Puente de red, según cualquiera de las reivindicaciones 8-9, caracterizado porque el registro de direcciones en proceso de reparación comprende las direcciones MAC destino en proceso de reparación y un temporizador de reparación superior al doble del tiempo necesario para que las tramas de reparación recorran la red.

11. Red de telecomunicaciones conmutada caracterizada porque comprende al menos un puente de red definido según alguna de las reivindicaciones 8, 9 o 10.


 

Patentes similares o relacionadas:

Imagen de 'Método y dispositivo para la comparación de versiones de datos…'Método y dispositivo para la comparación de versiones de datos entre estaciones a través de zonas horarias, del 29 de Julio de 2020, de Advanced New Technologies Co., Ltd: Un método para la comparación de versiones de datos entre sitios a través de zonas horarias, el método que comprende: cuando los sitios […]

Interacción de función de red de auto organización, del 15 de Julio de 2020, de TELEFONAKTIEBOLAGET LM ERICSSON (PUBL): Un método, mediante una función de Red de Auto Organización de alto nivel, SON, en una estructura jerárquica de funciones SON en una red, de […]

Procedimiento y sistema para diagnosticar averías de transmisión en una red según el estándar opc ua, del 24 de Junio de 2020, de SIEMENS AKTIENGESELLSCHAFT: Procedimiento para diagnosticar averías en la transmisión en una red de datos (NET), incluyendo la red de datos al menos una primera clase de elementos […]

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 […]

Autorización previa de establecimiento de portador, del 17 de Junio de 2020, de TELEFONAKTIEBOLAGET LM ERICSSON (PUBL): Un método para autorizar previamente la reserva de recursos portadores para un servicio antes de haber recibido una autorización de Calidad de Servicio, QoS, para el […]

Virtualización de funciones de red en grupos a medida, del 17 de Junio de 2020, de TELEFONAKTIEBOLAGET LM ERICSSON (PUBL): Un método para virtualizar una función de red entre un grupo a medida que comprende una pluralidad de terminales móviles ubicados unos […]

Dispositivo de motor de reglas de terminal y método de operación de regla de terminal, del 17 de Junio de 2020, de Advanced New Technologies Co., Ltd: Un método para procesar una operación de regla, el método que comprende: recibir, mediante un terminal, una solicitud de operación de regla de un servicio (S601); […]

Dispositivo de interfaz, procedimiento y programa informático para controlar dispositivos sensores, del 10 de Junio de 2020, de Ubiquiti Inc: Un primer dispositivo de interfaz para su uso en un sistema de domótica , comprendiendo el primer dispositivo de interfaz: un módulo de comunicación […]

Utilizamos cookies para mejorar nuestros servicios y mostrarle publicidad relevante. Si continua navegando, consideramos que acepta su uso. Puede obtener más información aquí. .