ES2540595A1

ES2540595A1 - Procedimiento de establecimiento y borrado de caminos y de reenvio de tramas para conexiones de transporte y puente de red

Info

Publication number: ES2540595A1
Application number: ES201301133A
Authority: ES
Inventors: Elisa ROJAS SÁNCHEZ; Guilermo IBÁÑEZ FERNÁNDEZ; Isaías MARTINEZ YELMO; Arturo Azcorra Saloña
Original assignee: INSTITUTE IMDEA NETWORKS; INST IMDEA NETWORKS; Universidad de Alcala de Henares UAH
Current assignee: INSTITUTE IMDEA NETWORKS; INST IMDEA NETWORKS; Universidad de Alcala de Henares UAH
Priority date: 2013-12-10
Filing date: 2013-12-10
Publication date: 2015-07-10
Anticipated expiration: 2033-12-10
Also published as: US20160308727A1; WO2015086877A1; ES2540595B2

Abstract

La presente invención describe mecanismos que exploran una red de puentes transparentes para establecer un camino específico por cada nueva conexión TCP establecida entre dos terminales. El nuevo camino lo inicia el puente frontera conectado al terminal origen al recibir un segmento TCP de tipo SYN para establecer una conexión TCP, encapsulando dicho segmento dentro de un paquete especial de petición de camino que es difundido por todos los enlaces de la red hasta el puente frontera destino. El camino es confirmado por el puente frontera del terminal destino mediante un paquete de aceptación en unidifusión que transporta encapsulado el segmento SYN+ACK de respuesta del terminal B, confirmando tanto la conexión TCP entre terminales como el camino elegido entre A y B. El camino se borra automáticamente cuando pasa un tiempo determinado sin utilizarse la conexión o al enviar el terminal un segmento FIN en ambos sentidos de la conexión.

Description

5 PROCEDIMIENTO DE ESTABLECIMIENTO Y BORRADO DE CAMINOS Y DE REENVIO DE TRAMAS PAFtA CONEXIONES DE TFtANSPORTE Y PUENTE DE RED SECTOR DE LA TECNICA La presente invenciOn se encuadra dentro del sector de las comunicaciones y de los dispositivos electronicos y/o aplicaciones informaticas que establecen las comunicaciones entre puentes de red transparentes. 10 ESTADO DE LA TECNICA Son conocidos los protocolos de establecimiento de caminos denominados Fast-Path y ARP-Path [G. Ibanez, 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 15 Center and Campus Networks", 17° IEEE Workshop on Local and Metropolitan Area Networks (LANMAN), New Jersey, USA, May 2010.] [G. Ibanez, 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 exploracion simultanea de toda la red mediante una trama de difusion como el ARP 20 Request y realizan el aprendizaje en los puentes atravesados de las direcciones MAC origen y su asociaciOn 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 25 caminos de Aa Cy de C a A. Estos caminos son aprendidos en los puentes de la red mediante la difusion por todos los enlaces de una trama como ARP Request o mediante su respuesta, una trama unidifusion como ARP Reply. Los puentes asocian a la direccion MAC origen de la trama el puerto por el que se recibe primero la trama y bloquean esta asociacion innpidiendo su modificaciOn durante un tempo suficiente de forma que las copias 30 recibidas en otros puertos de cada puente son descartadas por no estar asociada su direccion MAC origen al puerto por el que se reciben. Estos caminos tambien 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 2

Nº solicitud28/11/2014F.OEPM28/11/2014F.Efectiva

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 AIIPath 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 leaming 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]. 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.

Nº solicitud28/11/2014F.OEPM28/11/2014F.Efectiva

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 todos 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 tupla 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, tupla 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+ACKen un paquete PathReplycon 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 tupla 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 tupla {C,A,pC,pA} (abreviadamente, tupla CA) , asociándolos al identificador de caducidad anteriormente creado de la tupla 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 tupla CA y se reenvía por el puerto asociado a la tupla 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 tupla AC, actualizando el tiempo de llegada, confirmando y renovando la validez de la asociación..

Nº solicitud28/11/2014F.OEPM28/11/2014F.Efectiva

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 teoninal AaIC.

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 tupla 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.

Nº solicitud28/11/2014F.OEPM28/11/2014F.Efectiva

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 tuplas 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.

Nº solicitud28/11/2014F.OEPM28/11/2014F.Efectiva

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 TCPPath, 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.

Nº solicitud28/11/2014F.OEPM28/11/2014F.Efectiva

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 AIIPath f1ow-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 tuplas 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 (Path Request).

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.

Nº solicitud28/11/2014F.OEPM28/11/2014F.Efectiva

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 11 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 f1ags SYN o FI N 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 AII-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 Y3. 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 e. Los temporizadores de caducidad de cada tupla asociada al puerto están activados y vigentes al no haber transcurrido el tiempo límite para el borrado.

Nº solicitud28/11/2014F.OEPM28/11/2014F.Efectiva

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 e.:. 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 tupla Ae (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 tupla Ae 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+AeK activos. En este caso se recibe un segmento de dicho tipo desde el terminal e (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 PathReply. Esta trama se reenvía en unidifusión por el puerto asociado a la tupla previamente aprendida Ae, es decir, se encamina a través de los puentes 3, 4 Y 1. En los puentes 4 y 1 se aprende la tupla CA (camino hacia e) porque no hay ninguna entrada genérica anterior asociada a e 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 AeK activo. Este último segmento con origen A y destino e 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 tupla CA y pasando por los puentes 1, 4 Y 3, hasta llegar a e. Nótese que en el puente 3 no existe una entrada asociada a la tupla CA por ser el puente frontera de e, por lo que se utiliza la entrada genérica e para encaminar, aprendida en el primer paso por el protocolo ARP-Path.

Nº solicitud28/11/2014F.OEPM28/11/2014F.Efectiva

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, Yademás los caminos AC y CA creados por TCPPath también. En la práctica lo que sucedería en este caso es que las tuplas 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 ARPPath 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 tuplas 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 AIIPath 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 tupla CA, mientras que en la figura 9 el segmento FIN va desde el terminal C hasta el A borrando la tupla 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 11 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 TCPPath. La figura 11.a) muestra las entradas de un puente de tipo ARP-Path tras construir un camino entre los hosts A YC. 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 TCPPath y se apuntará su clave dentro de la tabla tal y como muestra 11.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

Nº solicitud28/11/2014F.OEPM28/11/2014F.Efectiva

origen sea C y se cumplan otra serie de parámetros (específicados 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 11.c).

s

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

10: 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.

Nº solicitud28/11/2014F.OEPM28/11/2014F.Efectiva

Claims

REIVINDICACIONES

1. Procedimiento de establecimiento de caminos, reenvío de tramas y borrado 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 de difusión destino; asociar, en una tabla, a efectos de reenvío 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; bloquear esta asociación durante un tiempo determinado, impidiendo la asociación de dicha dirección origen a otro puerto del puente; descartar las tramas recibidas por puertos distintos al asociado a la dirección origen de la trama durante el tiempo en que esté bloqueada esa asociación; reenviar las tramas unidifusión recibidas por el puerto del puente que esté asociado a la dirección MAC destino de la trama borrar, en la tabla, a efectos de reenvío, las asociaciones de direcciones 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; solicitar la reparación del camino mediante una trama de multidifusión cuando una trama con destino unidifusión llega a un puente que no tiene ningún puerto asociado en la tabla, a efectos de reenvío para dicha dirección MAC.

caracterizado por -La existencia de una etapa de establecimiento en la que, al recibir en un puerto de un puente de red con una identidad asignada a cada uno de sus puertos una trama que transporta un segmento TCP que tiene el indicador de solicitud de conexión SYN activado yel indicador ACK desactivado,

crear una nueva conexión, asignándole un identificador interno único de conexión TCP-Path y asociar dicho identificador a la combinación exacta de los campos siguientes contenidos en la trama que transporta el segmento TCP: dirección MAC origen, dirección MAC destino de la trama que transporta el segmento TCP y puertos de transporte TCP origen y destino de la cabecera del segmento TCP, en lo sucesivo "campos de la conexión TCP"; asociar, 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 de la trama y al instante de llegada de la trama; encapsular la trama conteniendo el segmento TCP dentro de una trama especial de multidifusión PathRequest con dirección destino la dirección de grupo multicast compartida por "todos los puentes TCP-Path" y con dirección origen la dirección MAC del puente que encapsula la trama.

-

La existencia de una etapa de confirmación y renovación, en la que, al recibir en un puente de red una trama conteniendo un segmento TCP con el indicador de solicitud de conexión SVN activado yel indicador ACK activado (segmento SVNACK),

confirmar y renovar la conexión, en la tabla, a efectos de reenvío, renovando

durante un tiempo determinado la vigencia de la asociación, creada

previamente en el puente al recibirse el paquete PathRequest, de los

"campos de la conexión TCP" de la trama recibida mencionados

anteriormente (direcciones MAC origen y destino e identidades de puerto

TCP origen y TCP destino) con el identificador de conexión, con la identidad

del puerto del puente que primero recibió la trama, con un indicador de

caducidad de la trama y con el instante de llegada de la trama;

encapsular la trama conteniendo el segmento TCP SVN-ACK dentro de una

trama especial de unidifusi6n PathReply, con dirección MAC origen la del

puente que la encapsula y destino la dirección MAC del puente que fue

asociado en el puente a dicha conexión tras la recepción del PathRequest

para dicha conexión.

-

La existencia de una etapa de borrado, en la que, al recibir en un puente de

red una trama conteniendo un segmento TCP con el indicador de solicitud de

conexión FIN activado; encapsular el segmento TCP dentro de una trama especial de unidifusión PathFlush dirigida al puente frontera destino por el puerto asociado a la dirección del terminal destino, con el campo de tipo de protocolo, Ethertype, con el valor asignado a "TCP-Path"; borrar, de la tabla, a efectos de reenvío, la asociación de los "campos de la conexión TCP" asociados al destino y los contenidos de los temporizadores asociados.

-

Al recibir en un puente de red una trama no incluida en los casos anteriores:

verificar su pertenencia a una conexión existente en el puente consultando los campos de conexión TCP: direcciones MAC origen y destino, puertos de transporte de origen y destino; en caso afirmativo: reenviar la trama por el puerto asociado a dicha conexión hacia el terminal destino y renovar el temporizador asociado a la dirección MAC destino; en los demás casos: si existe un camino específico TCP-Path asociado a la dirección MAC destino pero vinculado a un puerto del puente distinto al puerto en fallo, reenviar dicha trama por dicho puerto de salida. 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: enviar una trama multidifusión para iniciar el mecanismo de reparación de caminos.
2. Procedimiento según la reivindicación 1, caracterizado por, en la etapa de establecimiento, al recibir en un puente de red una trama de multidifusión PathRequest dirigida a la dirección de grupo de multidifusión "todos los puentes TCP-Path" y tipo de protocolo, campo en la trama usualmente conocido como Ethertype, con el valor de "TCP-Path";

asociar, en una tabla, a efectos de reenvío, las direcciones MAC origen y destino e identidades de puertos de transporte origen y destino de la trama original encapsulada dentro de la trama recibida ("campos de la conexión TCP") 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; asociar, en una tabla, a efectos de reenvío, la dirección MAC origen de la trama PathRequest a la identidad del puerto del puente que primero recibió la trama; comprobar si la dirección MAC destino de la trama encapsulada dentro de la trama PathRequest corresponde a un terminal conectado directamente al puente que recibe la trama; en caso afirmativo: desencapsular la trama y reenviarla al terminal destino por el puerto del puente asociado a dicho terminal; en los demás casos: reenviar la trama por todos los puertos excepto el puerto donde se recibió primero; encolarla en las colas de salida de los puertos del puente según criterios de prioridad configurados previamente.
3. Procedimiento, según la reivindicación 1, caracterizado por, en la etapa de confirmación y renovación, al recibir en un puente de red una trama de unidifusión PathReply con destino una dirección MAC de puente y con el tipo de protocolo, campo en la trama usualmente conocido como Ethertype, conteniendo el valor asociado a "TCP-Path";

asociar, en una tabla, a efectos de reenvío, las direcciones MAC origen y destino e identidades de puertos de transporte origen y destino de la trama original encapsulada dentro de la trama recibida ("campos de la conexión TCP"), 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; comprobar si la dirección MAC destino, del encapsulado exterior de la trama corresponde al puente que está procesando la trama; en caso afirmativo: desencapsular la trama y reenviarla al terminal destino por el puerto del puente asociado a dicho terminal; en los demás casos: reenviar la trama por el puerto asociado a las direcciones MAC origen y destino y puertos de transporte origen y destino de la conexión TCP-Path y renovar la asociación de los "campos de la conexión TCP" al puerto de reenvío.
4.

Procedimiento según la reivindicación 1, caracterizado por, en la etapa de borrado, al

recibir en un puente de red una trama de unidifusión PathFlush con el campo de tipo

de protocolo, Ethertype, con el valor asignado al protocolo "TCP-Path";

5

borrar, de la tabla, a efectos de reenvío, la asociación de los "campos de la conexión

TCP" asociados al destino y los contenidos de los temporizadores asociados, sin

modificar otras asociaciones de dichas direcciones MAC a puertos del puente que no

estén vinculadas a los puertos origen y destino indicados;

comprobar si la dirección MAC destino de la trama encapsulada dentro de la trama

10

PathFlush corresponde a un terminal conectado directamente al puente que recibe

la trama;

en caso afirmativo: desencapsular la trama y reenviarla al terminal destino por el

puerto del puente asociado a dicho terminal;

en

los demás casos: reenviar la trama PathFlush en unidifusión por el puerto

15

asociado a los "campos de la conexión TCp· recién borrados.
5.

Puente de red caracterizado porque dispone de los medios de procesamiento

apropiados para implementar el proceclimiento de las reivindicaciones 1 a 4.

20

6. Red de telecomunicaciones conmutada caracterizada por comprender al menos un

puente de red definido según la reivindicación 5.