ES2638292B2 - Procedimiento de establecimiento y borrado de caminos múltiples disjuntos, de reenvío de tramas y puente de red - Google Patents

Abstract

La presente invención describe mecanismos que exploran secuencialmente una red de puentes transparentes para establecer múltiples caminos bidireccionales disjuntos en enlaces o en nodos y enlaces, entre parejas de puentes frontera de la red, así como un puente de red que implementa dichos mecanismos. El puente frontera origen envía paquetes multidifusión de establecimiento de caminos hacia el puente destino que se propagan hasta el puente destino, el cual confirma cada establecimiento de camino disjunto. Los caminos se borran automáticamente cuando pasa un tiempo determinado sin haberse confirmado, sin utilizarse o al enviar el puente frontera un paquete de borrado explícito de un camino o de todos los caminos. El número de los caminos creados es parametrizable y ambos extremos se comunican el número de enlaces de salida para saber el máximo de caminos factible. Estos caminos disjuntos múltiples creados por los puentes frontera pueden ser utilizados por una entidad o protocolo que precise de caminos múltiples disjuntos por razones de reparto de carga, fiabilidad u otras.

Description

5

10

15

20

25

30

35

40

45

50

DESCRIPCIÓN

Procedimiento de establecimiento y borrado de caminos múltiples disjuntos, de reenvío de tramas 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 de red transparentes.

Estado de la técnica

Son conocidos los protocolos de establecimiento de caminos denominados Fast-Path y ARP- 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. 770772.], que establecen caminos mediante la exploración simultanea de toda la red mediante una trama de difusión como el ARP Request y realizan 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. El procedimiento de establecimiento de camino mencionado opera como sigue: En una red de puentes ARP-Path, dos terminales A y C establecen para comunicarse sendos caminos de A a C y de C a A Estos caminos son aprendidos en los puentes de la red mediante la difusión por todos los enlaces de una trama de difusión como ARP Request o mediante su respuesta, una trama unidifusión como ARP Reply. Los puentes asocian a la dirección MAC origen de la trama el puerto por el que se recibe primero la trama y bloquean esta asociación impidiendo su modificación durante un tiempo suficiente de forma que las copias recibidas en otros puertos de cada puente son descartadas por no estar asociada su dirección MAC origen al puerto por el que se reciben. Estos caminos también pueden establecerse de la forma ya conocida como Flow-Path al enviar un ARP Request (del cual se registra MAC origen e IP origen y destino en el puente frontera origen) y un ARP Reply de respuesta que confirma el camino bidireccional y simétrico asociado a las direcciones MAC origen y destino. [Elisa Rojas, Guillermo Ibáñez, Diego Rivera, Juan A Carral, "Flow-Path: An AllPath flow-based protocol", Proceedings of the 2012 IEEE 37th Conference on Local Computer Networks (October 2012) pp. 244-247].

Asimismo son conocidos los protocolos que asocian bajo ciertas condiciones la dirección MAC origen de tramas unidifusión a un puerto de entrada y verifican cuando reciben una trama unidifusión o multidifusión 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 82] [Mack-Crane et al. Media access control bridging in a mesh network. US 2010/0272108 A1].

Los protocolos de establecimiento de caminos para conexiones de transporte [G. Ibáñez, Method for establishing and clearing paths and forwarding trames for transport connections, and network bridge WO 2015086877 A1] permiten establecer caminos en la red mediante exploración directa de la misma con tramas de multidifusión replicadas en la red, pero de forma más específica, asociando cada camino a un flujo de datos, tomando en consideración campos adicionales transportados en las tramas tales como los puertos de transporte (TCP, UDP u otros) utilizados en la conexión entre los dos terminales para identificar cada flujo de datos y

5

10

15

20

25

30

35

40

45

50

utilizando el indicador SYN TCP en la trama recibida para comenzar la búsqueda de un nuevo camino para la nueva conexión de transporte de datos que dicho paquete SYN establece.

Es habitual igualmente en el estado de la técnica distinguir las tramas que debe procesar un protocolo mediante el campo Ethertype de la trama Ethernet
http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml]. Por ejemplo, el protocolo ARP tiene asignado el Ethertype 806h y trata los paquetes de control ARP porque la capa dos asocia ese tipo al protocolo, los paquetes de datos llevaran el ethertype 800h que corresponde a los paquetes IP, siendo por tanto procesados por el protocolo IP.

Pero ninguno de los protocolos mencionados garantiza que los diversos caminos creados sean disjuntos, es decir, que ningún camino comparta con otro un enlace (camino disjunto en enlaces) o bien no comparta ni enlace ni puente alguno (camino disjunto en puentes y por tanto en enlaces).

Son conocidos igualmente procedimientos de establecimiento de caminos múltiples conocidos como Equal Cost Multiple Path (ECMP) [RFC2992, C. Hopps, IETF 2000], en los que los caminos múltiples se obtienen mediante cálculo sobre un grafo que representa a la red en lugar de mediante la exploración física de la red mediante tramas.

En redes cableadas el protocolo más conocido que utiliza Equal Cost Multiple Path es Shortest Path Bridging [1]. Shortest Path Bridging requiere el conocimiento completo de la topología de la red y realizar cálculos extremadamente complejos sobre el grafo de la red (múltiples caminos mínimos simétricos entre nodos elegibles por prioridades ordenadas según la lista de identidades de puente, de complejidad computacional 0(N**3)) para obtener múltiples rutas disjuntas en el grafo de la red.

Para redes móviles Ad Hoc existen muchos protocolos orientados a redes inalámbricas y móviles, derivados del protocolo Ad Hoc Distance Vector (AODV) [3] o de Dynamic Source Routing (DSR) [2], protocolo basados en búsqueda explícita de rutas, con respuestas que contienen rutas explicitas. Split multipath (SMR) [4) extensión de DSR; Ad hoc On-demand Multi-path Distance Vector (AOMDV) routing protocol (rutas disjuntas en enlaces) [5], AODV- Multi-path protocol [6] (rutas disjuntas en nodos); Geographic Multi-path Routing Protocol (GMRP) [7] y Energy-aware Multi-path Routing Protocol (EMRP) [8]. Los protocolos derivados de AODV y DSR requieren comparación de los muchos paquetes duplicados con rutas que llegan a los puentes para actualizar la ruta recibida y retransmitir la más corta recibida.

Descripción de la invención

La presente invención describe mecanismos que permiten establecer (buscar un camino en la red y confirmarlo), utilizar y borrar múltiples caminos, parcial o totalmente disjuntos (disjuntos solamente en enlaces o bien disjuntos también en nodos (es decir, puentes) entre dos puentes frontera de una red que estén situados en cualquier punto de la red, así como un puente de red que implementa dichos mecanismos. Se entiende por camino parcialmente disjunto aquel que, teniendo algún enlace sin compartir con ninguno de los otros caminos, atraviesa algún enlace asignado a otro camino establecido entre los mismos puentes frontera y destino. La multiplicidad de los caminos creados es parametrizable.

Estos caminos entre puentes pueden ser asignados a flujos de tráfico entre terminales de diversas formas a fin de distribuir el tráfico entre los caminos disponibles

La invención incluye un procedimiento iterativo de búsqueda y confirmación de caminos disjuntos entre los puentes de la red, un procedimiento de reenvío de tramas de usuario a través de dichos caminos y un procedimiento para borrarlos. Estos procedimientos se aplicarán

5

10

15

20

25

30

35

40

45

50

por parte de los puentes Multiple_Disjoint_Path que tengan activada dicha funcionalidad, configurable según los requerimientos de la red. Estos caminos disjuntos múltiples creados por los puentes frontera pueden ser utilizados por una entidad o protocolo que precise de caminos múltiples disjuntos por razones de reparto de carga, fiabilidad u otras. Para ello se precisará de interfaces adecuadas para que otros dispositivos o programas puedan utilizar este servicio de establecimiento de caminos múltiples.

Establecimiento sucesivo de caminos múltiples disjuntos

Previo al establecimiento de caminos, cada puente precisa conocer la dirección MAC de los demás puentes frontera y de los terminales conectados a cada uno de ellos. El puente crea y mantiene una lista de los terminales que están conectados a él.

Los puentes utilizan un procedimiento para anunciar a los demás puentes su dirección MAC y la de los terminales conectados a ellos, de la forma siguiente: cuando un puente se inicializa, y después periódicamente, procede a establecer un camino genérico de todos los puentes hacia él emitiendo un paquete multidifusión SetTree con su dirección MAC como dirección origen y con dirección destino la dirección multidifusión asociada al protocolo Multiple_Disjoint_Path el específico asignado a Multiple_Disjoint_Path, conteniendo la trama la lista de terminales conectados al puente.

Cada puente, al recibir la trama Set tree, asocia el puerto por donde primero se recibe a la dirección origen del puente.

Búsqueda y confirmación de caminos múltiples disjuntos

La búsqueda de caminos múltiples utiliza el procedimiento conocido como FastPath y ARP-Path para la selección del camino más rápido en la red. Un puente frontera origen A establece hasta un número variable N de caminos múltiples disjuntos o parcialmente disjuntos (si los caminos comparten algún enlace) con un puente destino H de la forma siguiente:

En una red de puentes el puente frontera (también conocido como puente de acceso) comienza el establecimiento de caminos múltiples disjuntos enviando a cada uno de los demás puentes una trama de búsqueda de camino (Path Request) en multidifusión que contiene el puente destino, número de secuencia identificador de camino entre el par de puentes y un indicador de tipo de camino disjunto que inicialmente puede ir vacío. El paquete se reenvía por todos los puentes, aprendiéndose transitoriamente el camino (por asociación de la dirección MAC origen al primer puerto que recibe la trama y el bloqueo transitorio de esa asociación a nuevos asociaciones a otros puertos) hacia el puente origen en los puertos donde se recibe primero la trama y descartando los paquetes duplicados recibidos por otros puertos más tarde. Se asocian en una tabla, a efectos de reenvío, las direcciones MAC origen y destino, así como el número de secuencia identificador de camino múltiple #i, a la identidad del puerto del puente que primero recibió la trama, a un indicador de caducidad y al instante de llegada de la trama; y se reenvía en difusión por todos los puertos excepto por el puerto de recepción.

Cada puente que recibe la trama de búsqueda de camino #i (el número de secuencia del primer camino) asocia la dirección del puente (dirección MAC origen de la trama enviada) al puerto donde primero se recibe la trama y la reenvía por todos los puertos menos por el de llegada, la asociación de la dirección origen al puerto dura un tiempo suficiente para impedir la formación de bucles de forma que en cada puente solamente la trama recibida primero será la única retransmitida, porque las tramas duplicadas recibidas posteriormente por otros puertos son descartadas al ser recibidas por un puerto distinto al asociado a la dirección MAC origen de la trama.

5

10

15

20

25

30

35

40

45

50

Finalmente, solamente una trama de búsqueda de camino #i (el número de secuencia del primer camino) será aceptada (las recibidas por otros puertos serán descartadas por el propio puente) en el puente frontera H, el cual anota el puerto por donde recibe la trama y lo asocia a las direcciones de los dos puentes frontera A y H como camino #i (el número de secuencia del primer camino) bidireccional a utilizar. Para confirmar el establecimiento del primer camino bidireccional entre A y H, el puente H responde enviando una trama unidifusión de confirmación de camino #i (el número de secuencia del primer camino) por el puerto por donde se recibió, con dirección origen la dirección del puente H, dirección destino la dirección del puente A e identificador de protocolo (Ethertype) el específico asignado a Multiple_Disjoint_Path. Esta trama recorre en dirección contraria el camino entre A y H por lo que en cada puente de la red que recibe esta trama, la trama se reenvía por el puerto asociado a la dirección de A y se anota en su tabla de reenvío el camino bidireccional #i (el número de secuencia del primer camino) entre los puentes A y H y los dos puertos asociados a dicho camino bidireccional, quedando así el camino bidireccional #i (el número de secuencia del primer camino) entre A y H establecido, arrancándose un temporizador de validez del camino #i (el número de secuencia del primer camino) y un temporizador para el establecimiento del camino #i+1 (el número de secuencia del segundo camino).

El puente A, una vez establecido el camino disjunto #i (el número de secuencia del primer camino) procede a establecer un nuevo camino disjunto #i+1 (el número de secuencia del segundo camino) enviando un una trama de búsqueda de camino con número de secuencia identificador de camino #i+1 (el número de secuencia del segundo camino). Si el camino deseado es disjunto en enlaces, el puente A envía la petición indicando el tipo de camino disjunto en enlaces por todos los puertos menos por el puerto asociado al camino #i (el número de secuencia del primer camino) para evitar que el nuevo camino #i+1 (el número de secuencia del segundo camino) utilice enlaces ya asignados al camino #i. Cada puente que recibe la trama de búsqueda de camino #i+1 (el número de secuencia del segundo camino) aprende la dirección origen del puente A y la dirección MAC origen, la asocia al puerto por donde se recibe primero, y la reenvía por todos los demás puertos excepto por los puertos asociados al camino #i (el número de secuencia del primer camino)(puertos asociados a la pareja de direcciones MAC de los puentes A-B y al número de secuencia identificador de camino #i). Finalmente, solamente una o ninguna trama de búsqueda de camino #i+1 (el número de secuencia del segundo camino) será aceptada (las recibidas por otros puertos serán descartadas por el propio puente) en el puente frontera H, el cual anotara el puerto por donde recibe la trama y lo asocia a las direcciones de los dos puentes frontera A y H como camino #i+1 (el número de secuencia del segundo camino) bidireccional a utilizar. Para confirmar en todos los puentes atravesados el camino seleccionado el establecimiento del primer camino bidireccional entre A y H, el puente H responde enviando una trama unidifusión de confirmación de camino Path Confirm #i+1 (el número de secuencia del segundo camino) por el puerto por donde se recibió, con dirección origen la dirección del puente H y dirección destino la dirección del puente A. Esta trama recorre en dirección contraria el camino entre A y H por lo que en cada puente de la red que recibe esta trama, la trama se reenvía por el puerto asociado a la dirección de A y se anota en su tabla de reenvío el camino bidireccional #i+1 (el número de secuencia del segundo camino) entre los puentes A y H [y los terminales a y b] y los dos puertos asociados a dicho camino bidireccional quedando así el camino bidireccional #i+1 (el número de secuencia del segundo camino) entre A y H establecido, arrancándose un temporizador de validez del camino.

Si el camino deseado es disjunto en nodos, el puente A envía la petición indicando el tipo de camino disjunto en nodos por todos los puertos menos por el puerto asociado al camino #i (el número de secuencia del primer camino) para evitar que el nuevo camino #i+1 (el número de secuencia del segundo camino) utilice enlaces ya asignados al camino #i. Cada puente que recibe la trama de búsqueda de camino #i+1 (el número de secuencia del segundo camino) comprueba si tiene algún camino asignado con número de secuencia identificador de camino

5

10

15

20

25

30

35

40

45

50

menor que el de la trama recibida de búsqueda de camino y en caso afirmativo descarta la petición y no la reenvía. En caso negativo, aprende la dirección origen del puente A y la dirección MAC origen, la asocia al puerto por donde se recibe primero, y la reenvía por todos los demás puertos excepto por los puertos asociados al camino #i (el número de secuencia del primer camino) (puertos asociados a la pareja de direcciones MAC de los puentes A-B). Finalmente, solamente una o ninguna trama de búsqueda de camino #i+1 (el número de secuencia del segundo camino) será aceptada (las recibidas por otros puertos serán descartadas por el propio puente) en el puente frontera H, el cual anotara el puerto por donde recibe la trama y lo asocia a las direcciones de los dos puentes frontera A y H como camino #i+1 (el número de secuencia del segundo camino) bidireccional a utilizar. Este proceso se repite para los caminos sucesivos.

El paquete de búsqueda de camino Path Request contiene un campo que indica el número de enlaces del puente origen que le unen a otros puentes y están activos y otro campo con el número de caminos confirmados por el puente destino, el paquete Path Confirm contiene igualmente dos campos respectivamente con los mismos contenidos. El puente origen decide realizar nuevos intentos de establecimiento de caminos disjuntos en función de dichos campos y del número de intentos ya realizados. Igualmente el puente origen puede comenzar intentando establecer caminos disjuntos en nodos, luego disjuntos en enlaces y finalmente puede establecer caminos no necesariamente disjuntos si no alcanzara los suficientes para aprovechar al máximo la conectividad de la topología de red.

Borrado de caminos

Si los caminos no son utilizados por las tramas asociadas a ellos (tramas entre los terminales a y b) durante un tiempo superior al temporizador de persistencia (caché) de los puentes, expiran automáticamente, borrándose de la memoria los puertos asociados al camino.

Asimismo, cuando un camino establecido se interrumpe, por fallo de un enlace o de puente, se produce el borrado inmediato de las direcciones aprendidas en el puerto, asociadas en la tabla de reenvío al puerto conectado al enlace o puente en fallo y como consecuencia de los caminos asociados a dichas direcciones.

De manera similar al establecimiento, los caminos pueden ser borrados explícitamente por los puentes de los extremos mediante un paquete unidifusión Path Delete (borrado de camino) enviado por el camino y conteniendo el identificador de camino y el par de direcciones MAC de los puentes o un paquete multidifusión que indique borrado de todos los caminos entre el par de puentes origen y destino.

Reenvío de tramas

Las tramas recibidas en un puente pueden ser de control o de usuario (tramas de datos).

Si existe un camino múltiple asociado a la trama (según su tupla dirección MAC origen y MAC destino), se usa el procedimiento que sigue para reenviarla. Cada trama de usuario (datos) unidifusión recibida contiene la dirección MAC de terminal destino y la de origen. Con la dirección del terminal destino se consulta en la tabla global de terminales-puentes y se obtiene la dirección MAC del puente frontera al que está conectado el terminal destino. Para cada puente destino estarán ya creados entre 1 y n caminos disjuntos. Tanto en los puentes frontera como en los puentes intermedios, cada trama de datos se asocia de forma univoca a un camino de los múltiples establecidos entre los puentes origen y destino aplicando una función hash a la tupla formada por las direcciones origen y destino de los terminales, función cuyo resultado máximo coincida con el número de caminos disjuntos disponibles entre los puentes, asociando el resultado al camino correspondiente, si el resultado es cero al primer camino

5

10

15

20

25

30

35

40

45

50

asignado, si es 1 al segundo, y así sucesivamente. Si el resultado del hash es mayor que el número de caminos disponibles, se divide por dos dicho resultado y se vuelve a asignar.

Cada puente selecciona la función hash de forma coincidente, para que devuelva tantos resultados posibles como el número de caminos que hayan sido asignados entre los dos puentes. Este número lo obtiene cada puente, tanto frontera como intermedio, como la diferencia, incrementada en uno, entre los números de secuencia del último y del primer camino confirmados durante la última secuencia de establecimiento de caminos múltiples entre ambos puentes.

De esta forma cualquier puente de la red sabe a qué flujo/camino pertenece una trama a efectos de encaminamiento. La trama se envía por el puerto asociado a ese camino de acuerdo con el hash obtenido. En cada puente atravesado, el reenvío se realiza de la misma forma consultando el puerto de llegada y las direcciones MAC origen y destino, leyendo en la tabla el puerto de salida asociado al camino correspondiente. Si existe un puerto asociado a dicho camino como destino, se reenvía la trama por el puerto asociado a dicha conexión hacia el terminal destino y se renueva por un período adicional el temporizador asociado al número de camino múltiple; si no existe, se comprueba, de forma menos restrictiva, si existe algún puerto del puente asociado (por otro protocolo o procedimiento) solamente a la dirección MAC destino de la trama, si existe se reenvía la trama por dicho puerto.

Tras un tiempo sin ser utilizados, los caminos se borran. Los puentes frontera configurados para ello realizan de forma proactiva y periódica el establecimiento de caminos múltiples disjuntos entre los puentes mediante tramas multidifusión.

Al recibirse en un puente de red una trama de datos unidifusíón, tras consultar en la tabla los puentes origen y destino se comprueba si existen varios caminos múltiples para esa tupla de dirección origen y destino en la tabla de encaminamiento y en caso afirmativo, se realiza la función hash sobre la tupla de dirección MAC origen y MAC destino para determinar el camino a utilizar para el reenvío de esa trama.

Renovación de caminos

Cuando una trama de datos se recibe en un puente, el temporizador de validez del camino utilizado por la trama se renueva, prolongando su validez durante un intervalo adicional de caducidad desde que se recibe.

Puente de red para caminos múltiples disjuntos

Los mecanismos de establecimiento de caminos, borrado de caminos y reenvío de tramas descritos pueden implementarse en un puente de red que disponga de las correspondientes tablas para asociar los puertos a tuplas formadas por parejas de direcciones MAC a-b de los terminales y de los puentes frontera respectivos A-H así como de número de secuencia identificador de camino y del temporizador de duración del camino.

Descripción breve de los dibujos

La figura 1 muestra el diagrama de flujo del procedimiento para establecer los caminos múltiples disjuntos en enlaces.

La figura 2 muestra el procesado de las tramas recibidas en un puente y las acciones al vencer algún temporizador.

5

10

15

20

25

30

35

40

45

50

La figura 3 muestra la búsqueda del primer camino (identificador de camino #i) disjunto en enlaces entre dos puentes conectados a una red de puentes Multiple_Disjoint_Path y la confirmación con la trama de confirmación de camino Path Confirm.

La figura 4 muestra el establecimiento del camino disjunto en enlaces #i+1 (segundo camino) entre dos puentes frontera.

La figura 5 muestra el establecimiento del camino disjunto en enlaces #i+2 (tercer camino) entre dos puentes frontera.

La figura 6 muestra el establecimiento del camino disjunto en enlaces #i+3 (cuarto camino) entre dos puentes frontera.

La figura 7 muestra el estado de la red tras establecer los caminos.

La figura 8 muestra el borrado de un camino mediante Path Delete #i+2.

La figura 9 muestra la red tras el borrado del camino #i+2.

La figura 10 muestra el borrado de todos los caminos entre A y H mediante All Path Delete.

La figura 11 muestra el estado de los caminos tras el borrado posterior.

La figura 12 muestra el diagrama de flujo del procedimiento para establecer caminos múltiples disjuntos en nodos.

La figura 13 muestra el establecimiento del camino disjunto en nodos #i (el número de secuencia del primer camino) entre dos puentes frontera.

La figura 14 muestra el establecimiento del camino disjunto en nodos #i+1 (el número de secuencia del segundo camino) entre dos puentes frontera.

La figura 15 muestra el establecimiento del camino disjunto en nodos #i+2 entre dos puentes frontera.

La figura 16 muestra el intento fallido de establecimiento del camino disjunto en nodos #i+3 entre dos puentes frontera.

La figura 17 muestra el formato de una trama de control del protocolo Multiple_Disjoint_Path.

La figura 18 muestra el formato de una trama Set Tree.

La figura 19 muestra el formato de las tablas de un puente.

La figura 20 muestra el estado de la tabla 1 del puente C y el estado de las tablas 2 y 3 del puente A cuando se envía el Path Request 1. La tabla 2 existe en todos los puentes.

La figura 21 muestra el estado de la tabla 1 del puente C y el estado de las tablas 2 y 3 del puente A cuando se recibe la trama de confirmación de camino Path Confirm 1.

La figura 22 muestra el estado de la tabla 1 del puente C y de la tabla 2 del puente A cuando se envía el Path Request 2.

La figura 23 muestra el estado de la tabla 1 del puente C y de la tabla 2 del puente A cuando se recibe la trama de confirmación de camino Path Confirm 2.

5

10

15

20

25

30

35

40

45

50

La figura 24 muestra el estado de la tabla 1 del puente E y de la tabla 2 del puente A antes de enviarse el Path Delete para borrar el camino 3.

La figura 25 muestra el estado de la tabla 1 del puente E y de la tabla 2 del puente A una vez recibido el Path Delete 3.

Modo de realización

Se describe un modo de realización de la invención.

La figura 1 muestra la búsqueda del primer camino disjunto en enlaces entre dos puentes conectados a una red de puentes mediante el envío de la trama Path Request y la recepción de una trama de confirmación de camino Path Confirm.

La figura 2 muestra el diagrama de flujo para el procesamiento de las tramas recibidas y los temporizadores que expiran.

En la figura 3 se muestra una red de ejemplo para describir el mecanismo de exploración de la red para buscar caminos múltiples. Los terminales a y b representan a los grupos de terminales conectados respectivamente a los puentes frontera origen y destino A y H. Cada puente difunde periódicamente (mediante una trama de difusión Set Tree, ver figura 18) a todos los demás puentes su identidad (dirección MAC) y la lista de direcciones MAC de los terminales directamente conectados a dicho puente, direcciones que recopila de las direcciones MAC origen de los paquetes de difusión ARP Request recibidos y que los terminales envían espontáneamente. De esta forma todos los puentes construyen una tabla de direcciones MAC de terminal y puente destino asociado. Cuando un puente recibe una trama de un terminal, consulta en la lista de puentes-terminales a qué puente está conectado el terminal destino y la asocia a uno de los caminos múltiples establecidos previamente entre los puentes por el procedimiento que se describe mas adelante. Esa trama se encamina por uno de los caminos disponibles, obteniéndose el identificador del camino a usar mediante una función hash (resumen) aplicada a la tupla dirección MAC origen-dirección MAC destino.

La trama Set Tree está basada en la combinación de dos mecanismos conocidos en el estado de la técnica: los paquetes ESADI (End Station Address Distribution Information) Protocol (
https://tools.ietf.org/html/draft-ietf-trill-esadi-09) que distribuye la lista de terminales conectados a un RBridge y por otro lado el aprendizaje de dirección MAC origen del protocolo ARP-Path, asociando la mac origen de la trama a un puerto para crear un árbol de rutas hacia el puente que transmite la trama de difusión.

Cada puente establece los múltiples caminos de la forma que se describe a continuación para establecer entre los puentes origen y destino A y H. El puente origen A envía una trama Path Request, con el formato mostrado en la figura 17 con número de secuencia identificador de camino #i, tipo de camino disjunto en enlaces, y dirección destino multidifusión la asignada a todos los puentes Aii_Muitipie_Disjoint_Paths_Bridges, por todos los puertos conectados a otros puentes. En cada puente solamente la trama recibida primero será la única retransmitida, porque las tramas duplicadas recibidas posteriormente por otros puertos del puente durante el tiempo de bloqueo son descartadas al ser recibidas por un puerto distinto al asociado a la dirección MAC origen de la trama. La trama es retransmitida por todos los puertos excepto el de llegada. Cada puente atravesado analiza si la trama Path Request está destinada a él, en cuyo caso no la reenviará más. Finalmente, solamente una trama Path Request #i (el número de secuencia del primer camino) será aceptada en el puente frontera destino H (las tramas recibidas por otros puertos serán descartadas por el propio puente), el cual anota el puerto por donde recibe la trama y lo asocia a las direcciones de los dos puentes frontera A y H como camino #i (el número de secuencia del primer camino) bidireccional a utilizar. Para confirmar el

5

10

15

20

25

30

35

40

45

50

establecimiento del primer camino bidireccional entre A y H, el puente H responde enviando una trama unidifusión de confirmación de camino Path Confirm #i (el número de secuencia del primer camino), con el formato mostrado en la figura 17, por el puerto por donde se recibió, con dirección origen la dirección del puente H y dirección destino la dirección del puente A. Esta trama recorre en dirección contraria el camino entre A y H. Los puentes D y F reenvían la trama por el puerto asociado a la dirección de A y se anota en su tabla de reenvío el camino bidireccional #i (el número de secuencia del primer camino) entre los puentes A y H y los dos puertos asociados a dicho camino bidireccional quedando así el camino bidireccional #i (el número de secuencia del primer camino) entre A y H establecido, iniciándose un temporizador de validez del camino #i.

Como se muestra en la figura 4, el puente A, una vez establecido el camino disjunto #i (el número de secuencia del primer camino) procede a establecer un nuevo camino disjunto #i+1 (el número de secuencia del segundo camino), iniciando el temporizador de establecimiento para dicho camino y enviando un Path Request con número de secuencia identificador de camino #i+1. El puente A envía la petición por todos los puertos menos por el puerto asociado al camino #i (el número de secuencia del primer camino) para asegurar que el nuevo camino #i+1 utiliza distintos enlaces que el #i. Cada puente que recibe el Path Request #i+1 aprende la dirección origen del puen1e A y la dirección MAC origen y la asocia al puerto por donde se recibe primero, y la reenvía por todos los demás puertos excepto por los puertos asociados al camino #i (el número de secuencia del primer camino) (puertos asociados a la pareja de direcciones MAC de los puentes A-B). Finalmente, solamente una o ninguna trama Path Request #i+1 será aceptada (las recibidas por otros puertos serán descartadas por el propio puente) en el puente frontera H, el cual anotará el puerto por donde recibe la trama y lo asocia a las direcciones de los dos puentes frontera A y H como camino #i+1 bidireccional a utilizar. Para confirmar el establecimiento del camino i+1 bidireccional entre A y H, el puente H responde enviando una trama unidifusión de confirmación de camino Path Confirm #i+1 por el puerto por donde se recibió, con dirección origen la dirección del puente H y dirección destino la dirección del puente A. Esta trama recorre en dirección contraria el camino entre A y H por lo que en cada puente de la red que recibe esta trama, la trama se reenvía por el puerto asociado a la dirección de A y se anota en su tabla de reenvío el camino bidireccional #i+1 entre los puentes A y H y los dos puertos asociados a dicho camino bidireccional quedando así el camino bidireccional #i+1 entre A y H establecido, arrancándose el temporizador de validez del camino.

La figura 5 muestra el establecimiento y confirmación de un tercer camino disjunto en enlaces (#i+2) entre los puentes frontera y la figura 6 lo mismo para un cuarto camino (i+3) disjunto en enlaces. Las tramas son reenviadas solamente por los enlaces que no tienen un camino asociado previamente.

La figura 7 muestra los cuatro caminos establecidos, disjuntos en enlaces.

Borrado de caminos

Cuando la trama Path Delete (A, H) se envía a la dirección multidifusión específica All_Multiple_Disjoint_Paths_Bridges desde el puente A, dicha trama provocará el borrado del camino que se indica en las tablas de los puentes atravesados por la trama.

La figura 8 muestra el borrado de caminos mediante un paquete unidifusión Path Delate #

N. En la figura 8, la trama Path Delete #í+2 tiene como dirección origen la del puente A y como destino la del puente H, el tipo de protocolo Multiple_Disjoint_Path y el código de operación correspondiente a Path Delete. Se envía por el puerto de A correspondiente al camino #i+2 que se desea eliminar y es reenviada en unidifusión por cada puente hasta alcanzar el puente destino H.

5

10

15

20

25

30

35

40

45

50

En cada puente atravesado se borran las entradas correspondientes al camino #i+2 entre los puentes A y H (tupia A-H-camino #i+2).

La figura 9 muestra los caminos restantes tras el borrado del camino #i+2.

La figura 10 muestra el borrado de todos los caminos entre los puentes A y H mediante una trama All Path Delete multidifusión, trama que se envía por todos los puertos asociados a caminos A-H y lleva como dirección origen la del puente A y como destino la dirección multidifusión All_Multiple_Disjoint_Paths_Bndges. En cada puente atravesado se borran todos los caminos asociados al par de nodos A-H y se comprueba si la dirección de destino interna dLa trama (H) corresponde a la del puente alcanzado, en cuyo caso no se reenviara más la trama. En caso contrario, la trama se reenvía por todos los puertos del puente que estén asociados a caminos entre A y H.

La figura 11 muestra los caminos restantes tras el borrado de todos los caminos entre A y H.

Establecimiento sucesivo de caminos disjuntos en nodos

La figura 12 muestra el diagrama de flujo para el establecimiento de caminos disjuntos en nodos. El indicador de tipo de camino está en el valor disjunto en nodos.

La figura 13 muestra el establecimiento del primer (#i) camino disjunto en nodos, de forma similar al disjunto en enlaces. Al ser el primer camino y no haber caminos establecidos en ningún nodo, el camino más rápido es seleccionado y confirmado por H mediante de confirmación de camino Path Confirm #i.

La figura 14 muestra el establecimiento del camino #i+1 disjunto en nodos mediante la trama Path Request #i+1 enviada por todos los enlaces menos por el que ha confirmado camino y reenviada por los nodos que no tienen camino asignado, descartada por los nodos que tienen asignado el camino #i.

La figura 15 muestra el establecimiento del camino #i+2 disjunto en nodos, enviado a los nodos K y G, pero al llegar antes la trama reenviada por G, se crea un árbol bifurcado en G y cuya rama más rápida llega a H por el puente Ñ, siendo este camino el confirmado, expirando el camino GIJH por no ser confirmado.

La figura 16 muestra el intento fallido de establecimiento del camino disjunto en nodos #1+3. Se envía en multidifusión. La trama Path Request #i+3, por el enlace que le une a K por el único puerto no asignado a un camino y llega al puente K. El puente K no tiene puertos de salida sin asignar a caminos, por lo que lo descarta y no lo reenvía. Al no recibirse Path Request #i+3 en el puente H, su temporizador de establecimiento de siguiente camino expira y el puente da por terminado el proceso de establecimiento de caminos. Al no ser confirmado el camino #i+3, expira en cada uno de los puentes atravesados al vencer el temporizador de establecimiento de camino. En el puente frontera origen A, al no recibirse respuesta en tiempo al Path Request del camino #i+3, éste caduca y su entrada es borrada.

En cada puente, cuando una trama de datos llega por un puerto, se consulta la tabla de terminales-puente frontera (figura 19, tabla 3), obteniendo las direcciones de los puentes frontera origen y destino a los que están conectados. Realizando la función hash se obtiene el identificador del camino a utilizar, con lo que consultando en la tabla de encaminamiento del puente con la tupla MAC origen MAC destino y número de secuencia identificador de camino, se obtiene el puerto de salida del puente por el que encaminar la trama.

5

10

15

20

25

30

Bibliografía

[1] 802.1aq-2012-IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks-Amendment 20: Shortest Path Bridging.

[2] D. B. Johnson. D. A. Maltz and J. Broch, "DSR The Dynamic Source Routing Protocol for Multi-hop Wireless Ad hoc Networks". in Ad hoc Networking, Chapter 5, C. E. Perkins. Eds. Addison Wesley, pp. 139-172, 2000.

[3] C. E. Perkins and E. M. Royer, "Ad hoc On-demand Distance Vector Routing", Proceedings of the 2nd Annual IEEE International Workshop on Mobile Computing Systems and Applications, pp. 90-100, February 1999.

[4] S Lee and M. Gerla. "Split Multi-path Routing with Maximally Disjoint Paths in Ad Hoc Networks", Proceedings of IEEE International Conference on Communications. Vol. 10, pp. 3201-3205, 2001.

[5] M. K. Marina and S. R. Das. "On-demand Multi-path Distance Vector Routing in Ad Hoc Networks". Proceedings of the IEEE International Conference on Network Protocols. pp. 14-23, Nov. 2001.

[6] Z. Ye, S. V. Krishnamurthy and S. K. Tripathi, "A Framework for Reliable Routing in Mobile Ad Hoc Networks". Proceedings of the IEEE International Conference on Computer Communications. 2003.

[7] V. Loscri and S. Marano, "A New Geographic Multi-path Protocol for Ad Hoc Networks to Reduce the Route Coupling Phenomenon", Proceedings of the 63rd IEEE Vehicular Technology Conference, VTC 2006-Spring, Vol. 3. pp. 1102-1106, 2006.

[8] M. Li, L. Zhang, V. O. K. Li, X. Shan and Y. Ren. "An Energy-Aware Multi-path Routing Protocol for Mobile Ad Hoc Networks", Proceedings of the ACM SIGCOMM Asia, April 2005.

Claims (8)

1. 5

   10

   15

   20

   25

   30

   35

   40

   45

   50

   REIVINDICACIONES

   1. Procedimiento iterativo de establecimiento de caminos múltiples disjuntos de tramas de

   datos entre dos nodos frontera cualquiera de una red, que comprende las siguientes etapas:

   a) Información de terminales. Cada puente frontera envía una trama de multidifusión conteniendo la dirección del puente y la lista de las direcciones de los terminales conectados al puente;

   b) Etapa de búsqueda de camino, en la que cada puente realiza la búsqueda del camino más rápido hacia cada uno de los demás puentes, mediante el envío, por todos los enlaces activos del puente conectados a otros puentes, de una trama de multidifusión;

   Al recibirse en un puente, a través de un puerto con una identidad de puerto asignada, una trama que comprende una dirección MAC origen y una dirección de multidifusión destino;

   1. asociar, a continuación, en una tabla, a efectos del reenvío hacía atrás del puente, la dirección MAC origen de la trama recibida a la identidad del puerto que primero recibió la trama en dicho puente, a un indicador de caducidad de dicha asociación y al instante de llegada de la trama y reenviarla por todos los puertos activos del puente menos por el que se recibió;
2. 2. bloquear esta asociación desde su creación impidiendo durante un tiempo determinado la asociación de dicha dirección origen a otro puerto del puente;
3. 3. descartar las tramas de multidifusión recibidas por puertos distintos al asociado a la dirección origen de la trama durante el tiempo en que esté bloqueada esa asociación;

   c) Confirmación de camino. Cada puente destinatario de la trama de búsqueda confirma el camino seleccionado en la red en la etapa a), enviando al puente origen una trama unidifusión por el puerto por donde se recibió la trama de búsqueda;

   caracterizado por

   d) En la etapa a) de búsqueda de camino, la trama multidifusión de búsqueda de camino generada por el puente origen contiene al menos la dirección MAC del puente destino, el número de secuencia identificador del camino a establecer y el tipo de camino disjunto (disjunto en enlaces nodos, disjunto en nodos) a establecer;

   e) en la etapa a) indicada arriba, cuando la trama de búsqueda de camino llega a un puente de la red:

   - inspeccionar el puente el campo tipo de camino:

   - si el tipo de camino es disjunto en enlaces, reenviar la trama por todos los puertos libres (puertos sin ningún número de secuencia identificador de camino asociado), pero descartar la trama si todos los puertos tienen algún número de secuencia identificador de camino asociado;

   - si el tipo de camino es disjunto en nodos y ese puente ya tiene un número de secuencia identificador de camino asociado a ese par de nodos, descartar la trama. Si por el contrario el puente no tiene ningún camino asociado, asociar el identificador de camino, dirección MAC origen y dirección MAC destino al puerto

   5

   10

   15

   20

   25

   30

   35

   40

   45

   50

   por el que primero se recibió la trama, y reenviar dicha trama por los puertos que no están asociados a ningún camino entre dichos puentes;

   - si, como resultado de la inspección del tipo de camino la trama se va a reenviar por algún puerto o la dirección MAC del puente destino contenida dentro de la trama recibida es la del puente donde se recibió, crear una nueva entrada en la tabla, asociando las direcciones MAC del puente origen y del puente destino de la trama al puerto donde primero se recibió, al número de secuencia del camino, al instante de tiempo en el que llegó la trama y a un temporizador para el establecimiento (búsqueda y confirmación) del camino.

   - Comprobar si la dirección MAC de puente destino contenida dentro de la trama recibida es la del puente donde se recibió.

   En caso afirmativo:

   - Confirmar el establecimiento del camino enviando, por el puerto por donde se recibió la trama de multidifusión de búsqueda de camino, una trama unidifusión de confirmación de establecimiento del camino con dirección origen la del puente emisor, dirección destino la del puente origen de la trama de búsqueda de camino y conteniendo al menos el número de secuencia identificador de camino contenido en la trama de búsqueda, y un indicador del tipo de camino establecido (disjunto en enlaces, disjunto en nodos);

   En caso negativo:

   - Reenviar la trama por todos los puertos del puente menos por el que se recibió.

   f) Al recibir en un puente de red una trama unidifusión de confirmación de camino, como se

   describe en la etapa b) indicada arriba:

   - comprobar la existencia en tabla de una solicitud de camino con ese número de secuencia identificador pendiente de confirmación.

   En caso afirmativo:

   - confirmar la asociación de la tupla MAC origen-MAC destino al primer puerto por donde se recibió la trama de búsqueda de camino, al número de secuencia identificador de camino y al puerto por donde se recibió la trama de confirmación de camino;

   - iniciar el temporizador de caducidad del camino.

   En caso negativo: descartar la trama de confirmación de camino.

   - comprobar si el puente que recibe la trama de confirmación de camino es el destinatario final de la trama;

   En caso afirmativo,

   - desactivar el temporizador de establecimiento del camino que se ha confirmado.

   - descartar la trama de confirmación de camino.

   - Incrementar el número de secuencia identificador de camino en una unidad.

   5

   10

   15

   20

   25

   30

   35

   40

   45

   50

   55

   - Repetir desde la etapa b) el procedimiento de búsqueda de camino hasta la expiración del temporizador de establecimiento de camino por falta de respuesta del puente destino.

   En caso negativo, reenviar la trama por el puerto asociado al camino.
4. 2. Procedimiento de reenvío de tramas según la reivindicación 1, caracterizado por

   Al recibir en un puente de red una trama unidifusión cuyo campo tipo de protocolo no es el correspondiente a Multiple Disjoint Path:

   - comprobar si existe camino (puerto de salida asociado) para esa tupla de direcciones origen y destino en las tablas de encaminamiento;

   - en caso afirmativo, realizar una función hash (resumen) de dicha tupla cuyo resultado está asociado unívocamente a un camino y encaminar la trama por el camino resultante de dicho cálculo, por el puerto asociado a dicha tupla y al valor del número de secuencia identificador de camino;

   - en los demás casos: comprobar si existe algún puerto del puente asociado a la dirección MAC destino de la trama.

   - en caso afirmativo: reenviar la trama por dicho puerto;

   - en los demás casos: descartar la trama.
5. 3. Procedimiento según reivindicaciones 1 y 2, caracterizado por

   - Al expirar en un puente el temporizador de establecimiento de un camino:

   - Borrar entrada provisional de la tabla asociada a ese camino en construcción;
6. 4. Procedimiento según las reivindicaciones 1 y 2, caracterizado por las etapas adicionales de borrado y reenvío,

   Al recibir en un puente de red una trama conteniendo una trama Path Delete #N:

   - borrar, de la tabla, a efectos de reenvío, la asociación de la tupla MAC origen-MAC destino y número de secuencia identificador de camino a los puertos del puente, para los caminos con esa tupla MAC origen-MAC destino y número de secuencia identificador de camino #N;

   - borrar, de la tabla, a efectos de reenvío, todas las asociaciones de la tupla MAC origen- MAC destino en el caso de que el contenido del campo de número de camino contenga el valor "todos los caminos entre puente origen y destino".

   - reenviar la trama por todos los puertos, excepto por el que se recibió.
7. 5. Puente de red caracterizado por disponer de los medios de procesamiento apropiados para implementar el procedimiento de las reivindicaciones 1 a 4.
8. 6. Red de telecomunicaciones conmutada caracterizada por comprender al menos un puente de red definido según la reivindicación 5.