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, 201 1 , 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 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 caminos 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 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 Ibanez, Diego Rivera, Juan A. Carral, "Flow-Path: An AHPath 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. US201 1/0032825A1 . Multipath discovery in switched Ethernet networks. Fecha de publicación, 10 de febrero de 201 1.] [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 solamente aprenden direcciones MAC por lo cual tampoco pueden distribuir el tráfico por flujos ni por aplicaciones o procesos usuarios dentro de una misma máquina.

Los anteriores protocolos presentan, entre otros, el inconveniente de que todas las aplicaciones comunicándose entre dos máquinas, por lo tanto enviando y recibiendo tramas con una misma dirección MAC destino o par de direcciones origen y destino, probablemente compartan los mismos caminos y no pueden distribuir la carga de los flujos entre dos terminales por caminos distintos con una granularidad más fina diversificando los caminos según dichos flujos.

Por ello son de utilidad protocolos y mecanismos que permitan 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 para identificar cada flujo 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.

DESCRIPCIÓN DE LA INVENCIÓN

La presente invención describe mecanismos que permiten buscar, establecer, utilizar y borrar un camino específico para cada conexión TCP establecida entre dos terminales y un puente de red que implementa dichos mecanismos. La diversidad de los caminos creados es parametrizable. La invención incluye un procedimiento de establecimiento de caminos en la red asociados a cada nuevo flujo de la capa de transporte TCP al establecer una nueva conexión TCP entre dos terminales, un procedimiento de reenvío de tramas a través de dichos caminos y un procedimiento para borrarlos al cerrar las conexiones TCP. Estos procedimientos se aplicarán por parte de los puentes TCP-Path que tengan activada dicha funcionalidad, configurable según los requerimientos de la red.

Establecimiento de caminos

Cuando, según se describe en el estado de la técnica más arriba, estando creado el camino ARP-Path entre dos terminales A y C se recibe un segmento TCP SYN en el puente frontera del terminal emisor (A) el segmento se encapsula en una trama especial PathRequest con dirección origen la dirección MAC del terminal emisor A e identificador de protocolo (Ethertype) el específico asignado a TCP-Path y se asocian, en una tabla, a efectos de reenvío, las direcciones MAC origen y puerto TCP origen, así como el identificador de la conexión TCP-Path, 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 tados los puertos excepto el puerto de recepción. En cada puente de red atravesado se realiza la asociación de la misma forma y,si el puerto de recepción de la trama proveniente de A es diferente al asociado al camino hacia A ya existente, se registra un camino alternativo asociando dicho puerto a la tupia formada por la dirección MAC origen A, dirección MAC destino C, puerto de transporte TCP usado por A y puerto de transporte TCP usado por C {A,C,pA,pC} (abreviadamente, tupia AC) , a un identificador de caducidad y al instante de llegada de la trama. Se comprueba en cada puente si la dirección MAC destino de la trama encapsulada dentro de la trama PathRequest es la de algún terminal conectado directamente al puente atravesado. Las tramas PathRequest duplicadas que llegan después por otros puertos son descartadas por no estar su dirección MAC origen asociada al puerto de recepción. Finalmente, solamente un paquete PathRequest conteniendo el segmento SYN llegará al puente frontera, conectado directamente al terminal C. El puente desencapsulará la trama y la reenviará al terminal C, asociando igualmente un identificador de caducidad a las direcciones MAC y TCP origen y al instante de llegada de la trama. El terminal C contestará con un segmento SYN+ACK confirmando el establecimiento de la conexión TCP. El puente frontera destino (conectado a C) encapsula el segmento SYN+ACK en un paquete PathReply con dirección MAC origen C, dirección MAC destino A e identificador de protocolo (Ethertype) el asignado al protocolo TCP-Path, y lo reenvía en unidifusión por el puerto asociado a la tupia AC, previamente asociada a dicho puerto cuando se recibió el paquete PathRequest. A su vez, el puente asocia (aprende) la dirección MAC de C, la dirección MAC de A, el puerto de transporte de C y el puerto de transporte de A al puerto por donde se ha recibido, identificados como la tupia {C,A,pC,pA} (abreviadamente, tupia CA) , asociándolos al identificador de caducidad anteriormente creado de la tupia AC, actualizando el tiempo de llegada, confirmando y renovando la validez de la asociación.. En cada puente atravesado se asocia igualmente el puerto de recepción a dicha tupia CA y se reenvía por el puerto asociado a la tupia AC, asociada a la conexión desde C hacia el terminal A, confirmando y renovando el camino en dirección hacia A , asociándolos al identificador de caducidad anteriormente creado de la tupia AC, actualizando el tiempo de llegada, confirmando y renovando la validez de la asociación..

Con el fin de aumentar la diversidad de caminos, cuando un puente recibe el paquete PathRequest por el mismo puerto que ya tenía asociado al camino genérico ARP-Path para A, dicho puente puede asociar el camino de transporte a un puerto distinto siempre que reciba el PathRequest duplicado con una diferencia de tiempo reducida y limitada respecto al puerto que primero lo recibe.

El paquete PathReply llega finalmente en unidifusión hasta el puente frontera de destino, al cual está conectado directamente el terminal destino A. El puente desencapsula la trama conteniendo el segmento original SYN+ACK y la reenvía al terminal A. El terminal A responderá con una trama conteniendo un segmento de transporte con el indicador ACK activado, el cual será reenviado como un segmento normal, sin encapsular, por el camino asociado a esa pareja de direcciones MAC y al par de puertos TCP de la conexión. De la misma forma serán encaminados los sucesivos segmentos de datos enviados del terminal A al C.

El protocolo TCP-Path encapsula los segmentos de transporte que contienen el indicador SYN activado (solamente el indicador SYN o bien los indicadores SYN y ACK activados), y establece y confirma con ellos caminos alternativos a los ya existentes, previamente establecidos mediante alguno de los protocolos conocidos: ARP-Path o Flow-Path. El camino de A a C puede existir previamente o no, tanto como camino ARP-Path asociado solamente a la dirección MAC A o como camino bidireccional Flow-Path asociado a las direcciones A y C, la diferencia radica en que TCP-Path sólo establece un camino nuevo asociado a la conexión si no existe camino previo entre A y C o, si existiendo, éste es diferente del que está siendo creado (es decir, el puerto asociado a la tupia es diferente del ya existente). Como consecuencia, el camino de transporte TCP-Path establecido entre A y C puede parcial, completamente, o en absoluto coincidir con los caminos preexistentes. Sólo habrá un camino entre A y C establecido por ARP-Path y Flow-Path, mientras que TCP-Path puede crear tantos caminos adicionales como conexiones de transporte existan en cada momento.

Los caminos establecidos se refrescan, prolongando su validez, automáticamente al recibirse tramas del flujo asociado al camino. Este refresco puede ser hacia delante y opcionalmente bidireccional, según se configure. En el refresco hacia delante las tramas recibidas renuevan la asociación de la MAC destino de la trama reenviada al puerto de salida. En el bidireccional renuevan también la asociación de la dirección MAC origen al puerto de entrada.

Borrado de caminos

Si los caminos no se utilizan por las tramas asociadas a ellos (con tupias de puertos de transporte y direcciones MAC en la tabla de reenvío) 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.

De manera similar al establecimiento, los caminos TCP-Path pueden ser borrados explícitamente por los terminales cuando envían un segmento FIN en cada dirección para cerrar la conexión TCP. Un terminal enviará un segmento FIN que es respondido por el terminal destino con un segmento ACK. Este segmento FIN cerrará la conexión TCP-Path en el sentido del segmento FIN enviado. Igualmente sucederá desde el extremo remoto cuando se emita un segmento FIN contestado con un segmento ACK hacia el extremo remoto para cerrar la conexión en el sentido remoto-cercano. Alternativamente, el extremo receptor puede contestar con un segmento combinado FIN+ACK (el denominado cierre TCP de tres vías), que será contestado con un segmento ACK para confirmar el cierre en el sentido remoto-cercano. Este segmento ACK no se encapsula.

Más concretamente, cuando el puente frontera recibe un segmento TCP con el indicador FIN activado, encapsula el segmento en un paquete PathFlush con direcciones origen y destino iguales a las del segmento recibido, el cual es reenviado en unidifusión hacia el destino siguiendo el camino establecido por CA, para así borrar el camino de A hacia C asociado a esa conexión TCP. El siguiente puente atravesado, al recibir dicha trama de unidifusión PathFlush con el campo de tipo de protocolo, conteniendo el valor asignado al protocolo "TCP-Path", borra de la tabla, a efectos de reenvío, la asociación de dirección MAC destino y puerto de transporte destino al puerto del puente y el contenido del temporizador de caducidad asociado, sin modificar otras asociaciones de dicha dirección MAC a otros puertos del puente; comprueba asimismo si la dirección MAC destino de la trama encapsulada dentro de la trama PathFlush corresponde a un terminal conectado directamente al puente que recibe la trama y, en caso afirmativo, desencapsula la trama y la reenvía al terminal destino por el puerto del puente asociado a dicho terminal. Si la dirección MAC destino de la trama encapsulada no está asociada a un terminal conectado directamente al puente que recibe la trama, el puente reenvía la trama PathFlush en unidifusión por el puerto asociado a los "campos de la conexión TCP" recién borrados.

Reenvío de tramas

Cuando una trama de datos se recibe en un puente TCP-Path, se consultan los campos de conexión TCP: direcciones MAC origen y destino, puertos de transporte de origen y destino, y se verifica si existe un puerto asociado a dicha conexión como destino; si existe, 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 a la dirección MAC destino y conexión TCP-Path asociada; si no existe, se comprueba, de forma menos restrictiva, si existe algún puerto del puente asociado a la dirección MAC destino de la trama o al par dirección MAC destino y MAC origen de la trama; si existe se reenvía la trama por dicho puerto; en los demás casos se iniciará el proceso de reparación de caminos mediante el envío de una trama de multidifusión. Es decir, cuando no existe un camino específico TCP-Path, puede ser utilizado por las tramas recibidas otro camino específico TCP-Path destinado a la misma dirección MAC destino o bien un camino genérico asociado solamente a dicha dirección MAC (creado mediante ARP-Path o Flow- Path). Si no hay camino genérico activo, uno de los caminos específicos TCP-Path pasará a ser genérico, asociándolo a la dirección MAC destino, para ser utilizado por todas las tramas con ese destino.

Si no existe ningún camino genérico, se repara el camino genérico con la reparación habitual de ARP-Path o Flow-Path descrita en [Elisa Rojas, Guillermo Ibanez, Diego Rivera, Juan A. Carral, "Flow-Path: An AHPath flow-based protocol", Proceedings of the 2012 IEEE 37th Conference on Local Computer Networks (October 2012) pp. 244-247].

Puente de red para caminos TCP-path

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 tupias formadas por parejas de direcciones MAC y de puertos de transporte origen y destino.

DESCRIPCIÓN BREVE DE LOS DIBUJOS

La figura 1 muestra el diagrama de flujo del protocolo para establecer los caminos por flujo TCP.

La figura 2 muestra el establecimiento previo, en una red de conmutadores TCP-Path, de caminos ARP-Path entre dos terminales A y C, asociados a las direcciones MAC de ambos, mediante el intercambio de los mensajes ARP Request y ARP Reply.

La figura 3 muestra la búsqueda de un camino TCP-Path tras la recepción de un segmento de transporte TCP con SYN activado (PathRequest).

La figura 4 muestra la confirmación del camino en sentido contrario con el segmento de transporte TCP con SYN y ACK activados (PathReply). En la figura 5 se muestra el segmento ACK (tercera fase del acuerdo de tres vías) emitido por el terminal A como respuesta al SYN+ACK reenviado por el nuevo camino TCP-Path establecido. La figura 6 muestra un caso en que no se crea ningún camino adicional TCP-Path en la red porque el camino genérico ARP-Path preexistente es el más rápido.

La figura 7 muestra el caso en que se crea un camino adicional TCP-Path nuevo totalmente disjunto del camino genérico ARP-Path preexistente.

Las figuras 8 y 9 muestran el borrado de caminos con segmentos FIN (PathFlush).

La figura 10 muestra la red tras ser borrados los caminos TCP-Path. La figura 1 1 muestra el aprendizaje que se realiza en las tablas de encaminamiento de un puente que tenga la funcionalidad TCP-Path activada.

MODO DE REALIZACIÓN

Se describe un modo de realización de la invención. La figura 1 muestra la lógica de funcionamiento del puente para establecer los caminos en forma de diagrama de flujos. Al recibir una trama lo primero que se mira es si se trata de un segmento de transporte con los flags SYN o FIN activados, encapsulándose en el correspondiente paquete PathRequest (SYN), PathReply (SYN+ACK) o PathFlush (FIN) de ser así. Si no es un segmento del tipo anterior, se analiza si se trata de una trama especial All-Path (PathRequest, PathReply o PathFlush), en cuyo caso se aprende o se borra el camino siguiendo la lógica de TCP-Path. Por último, si no es ninguno de los anteriores casos, se utiliza la lógica de funcionamiento de los protocolos ARP-Path y Flow-Path genérica.

En la figura 2 se muestra una red de ejemplo para examinar el mecanismo de aprendizaje, borrado y reparación de TCP-Path. Los terminales A, B y C están conectados respectivamente a los puentes frontera 1 , 7 y 3. Estos puentes tienen establecidos caminos entre ellos mediante el protocolo ARP-Path, basado en el aprendizaje de la dirección MAC origen de los paquetes ARP Request y ARP Reply emitidos por dichos terminales al comenzar a comunicarse. Se indica con un círculo rodeando una letra junto a cada puente, el puerto al que está asociada la dirección de dicho terminal (dirección aprendida). Por ejemplo, el camino hacia A está establecido en ciertos puertos de los puentes 3, 2 y 1 , mientras que el camino hacia C se ha creado sobre los puentes 1 , 6, 5 y 3. Se muestra así la dirección de las tramas en caso de haber tráfico de comunicación entre los terminales A y C. Los temporizadores de caducidad de cada tupia asociada al puerto están activados y vigentes al no haber transcurrido el tiempo límite para el borrado.

En la figura 3 se muestra el aprendizaje realizado al recibir el primer segmento de transporte con el flag SYN activo desde el terminal A. Este segmento tiene como origen A y como destino C. En el puente frontera 1 se encapsula en una trama PathRequest que es difundida por toda la red. Así pues, todos los puentes reciben una copia de la trama y apuntan la tupia AC (camino hacia A) en uno de sus puertos (excepto el puente 1 que es el frontera del terminal A), descartando las copias lentas las cuales se indican en la figura con una X. En este caso, sólo los puentes 1 , 2 y 3 tenían un camino previo hacia A, por lo que el puente 3 aprende la tupia AC porque la recibe por un puerto diferente que la actual entrada de A, el puerto conectado al puente 4, sin embargo el puente 2 la descartará al haber sido recibida por el mismo puerto que la actual entrada de A, que es por el puerto por el cual está conectado al puente 1.

A continuación, en la figura 4 se expone el comportamiento al recibir un segmento de transporte con los flags SYN+ACK activos. En este caso se recibe un segmento de dicho tipo desde el terminal C (como respuesta al SYN previo que iba dirigido de A a C) y es el puente frontera 3 el que se encarga de encapsularlo en una trama PathRepIy. Esta trama se reenvía en unidifusión por el puerto asociado a la tupia previamente aprendida AC, es decir, se encamina a través de los puentes 3, 4 y 1 . En los puentes 4 y 1 se aprende la tupia CA (camino hacia C) porque no hay ninguna entrada genérica anterior asociada a C y por lo tanto no puede coincidir en puerto con ninguna de ellas. Finalmente en la figura 5 podemos ver la última parte del inicio de conexión TCP, que es un segmento de transporte con el flag ACK activo. Este último segmento con origen A y destino C no tiene el flag SYN activo, por lo que el puente frontera 1 no lo encapsula y lo trata como a cualquier otra trama de tráfico de dicha conexión recién iniciada, encaminándolo por los puertos asociados a la tupia CA y pasando por los puentes 1 , 4 y 3, hasta llegar a C. Nótese que en el puente 3 no existe una entrada asociada a la tupia CA por ser el puente frontera de C, por lo que se utiliza la entrada genérica C para encaminar, aprendida en el primer paso por el protocolo ARP-Path. Las figuras 6 y 7 muestran dos casos extremos de posibles caminos creados mediante TCP-Path. En la figura 6 los caminos A y C creados por ARP-Path coinciden en dirección, atravesando ambos los puentes 1 , 2 y 3, y además los caminos AC y CA creados por TCP-Path también. En la práctica lo que sucedería en este caso es que las tupias AC y CA no se anotarían, al coincidir con los puertos de las entradas genéricas A y C ya existentes, por lo que no habría camino alternativo, situación que puede darse en caso de que el camino 1 , 2 y 3 siga siendo el camino más rápido y no esté muy utilizado todavía. En el caso de la figura 7 se muestra el extremo contrario, aquel en el que los caminos genéricos de ARP-Path A y C no comparten puentes (salvo los puentes frontera 1 y 3), y además el camino TCP-Path entre A y C atraviesa también puentes diferentes (pasando por el puente 4). Este último caso podría darse cuando todos los caminos son igual de rápidos y se distribuirían por igual por toda la red. Nótese que los caminos TCP-Path son simétricos, por lo que las tupias AC y CA siempre comparten puentes en uno y otro sentido (en este caso 1 , 4 y 3), mientras que los caminos genéricos ARP-Path no tienen por qué serlo.

Las figuras 8, 9 y 10 muestran el borrado de las entradas AC y CA mediante las tramas All-Path de tipo PathFlush. Estas tramas se crean al encapsular segmentos de transporte que contengan el flag FIN activo (ya sean FIN o FIN+ACK). En la figura 8 se envía un segmento FIN del terminal A hasta el C, borrando la tupia CA, mientras que en la figura 9 el segmento FIN va desde el terminal C hasta el A borrando la tupia que queda, la AC. Finalmente la figura 10 muestra cómo quedaría la red tras el borrado de los caminos TCP-Path en las figuras anteriores mediante la trama PathFlush.

En la figura 1 1 podemos ver qué significa cada círculo (A, C, AC o CA), es decir, cada una de las entradas en tabla de un puente que funcione siguiendo la especificación de TCP-Path. La figura 1 1 .a) muestra las entradas de un puente de tipo ARP-Path tras construir un camino entre los hosts A y C. Estas entradas se componen de una clave de búsqueda (en este caso la dirección MAC), un puerto asociado, un temporizador o timer y un estado 'Locked' (Bloqueado) o 'Learnt' (Aprendido). Cuando llega una nueva trama PathRequest asociada a un mensaje SYN del protocolo TCP y con origen A y destino C, si la primera copia llega por un puerto diferente al ya asociado, se produce un aprendizaje de tipo TCP-Path y se apuntará su clave dentro de la tabla tal y como muestra 1 1 .b). Es decir, la entrada con clave A será la entrada genérica para alcanzar el destino A, mientras que AC- ^* será la clave concreta del camino de TCP-Path con destino A, pero que sólo se utilizará cuando el origen sea C y se cumplan otra serie de parámetros (especificados con ^* ) como pueden ser números de puertos, etc. Con la respuesta de C hacia A, SYN+ACK encapsulado en un mensaje PathReply, si ésta llega por un puerto diferente al ya asociado a C, se realizará un aprendizaje análogo (figura 1 1.c).

Por lo tanto, además del camino base, se crearán caminos adicionales con claves más concretas, mientras que el resto de entradas de la tabla serán análogas.

Por otro lado, cuando llegue una trama de datos con destino A, se realizarán ahora dos búsquedas, una específica de clave y otra genérica si no se encontró la primera. Pero a su vez, si el camino específico sí existía y se borró por un fallo de enlace, esto garantiza que seguirá siendo posible el uso del camino base, o genérico, para el encaminamiento.