ES2540595B2 - Procedimiento de establecimiento y borrado de caminos y de reenvio de tramas para conexiones de transporte y puente de red - Google Patents

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

DESCRIPCION

PROCEDIMIENTO DE ESTABLECIMIENTO Y BORRADO DE CAMINOS Y DE REENVIO DE TRAMAS PARA CONEXIONES DE TRANSPORTE Y PUENTE DE RED

SECTOR DE LA TECNICA

5

La presente invention se encuadra dentro del sector de las comunicaciones y de los dispositivos electrdnicos y/o aplicaclones informaticas que establecen las comunicaciones entre puentes de red transparentes.

10 ESTADO DE LA TIiCNICA

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 exploration 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 terminates A y C establecen para comunicarse sendos 25 caminos de A a C y 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 direction MAC origen de la trama el puerto por el que se recibe primero la trama y bloquean esta asociacion impidiendo su modification durante un tiempo suficiente de forma que las copias 30 retibidas en otros puertos de cada puente son descartadas por no estar asociada su direction 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

5

10

15

20

25

30

frontera origen) y un ARP Reply de respuesta que confirma el camino bidireccional y simetrico asociado a las direcciones MAC origen y destino. [Elisa Rojas, Guillermo Ibanez, 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 direccion MAC origen de tramas unidifusion a un puerto de entrada y verifican cuando reciben una trama unidifusion o multidifusion si el puerto esta asociado o no a dicha trama [Minkenberg et al. US2011/0032825A1. Multipath discovery in switched Ethernet networks. Fecha de publication, 10 de febrero de 2011.] [Tanaka et al. First arrival port learning method, relay apparatus, and computer product. US 7760667 B2] [Mack-Crane et al. Media access control bridging in a mesh network. US 2010/0272108 A1], Estos protocolos solamente aprenden direcciones MAC por lo cual tampoco pueden distribuir el trafico 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 comunicandose entre dos maquinas, por lo tanto enviando y recibiendo tramas con una misma direccion 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 masfina diversificando los caminos segun dichos flujos.

Por ello son de utilidad protocolos y mecanismos que permitan establecer caminos en la red mediante exploration directa de la misma con tramas de multidifusion replicadas en la red, pero de forma mas especifica, asociando cada camino a un flujo de datos, tomando en consideration para identificarcada flujo campos adicionales transportados en las tramas tales como los puertos de transporte (TCP, UDP u otros) utilizados en la conexion entre los dos terminales.

DESCRIPCION DE LA INVENCION

La presente invencion describe mecanismos que permiten buscar, establecer, utilizar y borrar un camino especifico para cada conexion TCP establecida entre dos terminales y un puente de red que implementa dichos mecanismos. La diversidad de los caminos

5

10

15

20

25

30

creados es parametrizable. La invention 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 conexion TCP entre dos terminates, un procedimiento de reenvio de tramas a traves de dichos caminos y un procedimiento para borrarlos al cerrar las conexiones TCP. Estos procedimientos se aplicaran por parte de los puentes TCP-Path que tengan activada dicha funcionalidad, configurable segun los requerimientos de la red.

Establecimiento de caminos

Cuando, segun se describe en el estado de la tecnica mas arriba, estando creado el camino ARP-Path entre dos terminates 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 direction origen la direction MAC del terminal emisor A e identificador de protocolo (Ethertype) el especifico asignado a TCP-Path y se asotian, en una tabla, a efectos de reenvio, las direcciones MAC origen y puerto TCP origen, asi como el identificador de la conexion TCP-Path, a la identidad del puerto del puente que primero recibio la trama, a un indicador de caducidad y al instante de llegada de la trama; y se reenvia en difusion por todos los puertos excepto el puerto de reception.

En cada puente de red atravesado se realiza la asociacion de la misma forma y,si el puerto de reception de la trama proveniente de A es diferente al asociado al camino hacia A ya existente, se registra un camino altemativo asociando dicho puerto a la tupla formada por la direction MAC origen A, direction 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 direction MAC destino de la trama encapsulada dentro de la trama PathRequest es la de algun terminal conectado directamente al puente atravesado. Las tramas PathRequest duplicadas que llegan despues porotros puertos son descartadas por no estar su direction MAC origen asociada al puerto de reception. Finalmente, solamente un paquete PathRequest conteniendo el segmento SYN llegara al puente frontera, conectado directamente al terminal C. El puente desencapsulara la trama y la reenviara 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 contestara con un segmento SYN+ACK confirmando el establecimiento de la conexion TCP. El puente frontera destino (conectado a C) encapsula el segmento SYN+ACK en un paquete PathReply con direction

5

10

15

20

25

30

MAC origen C, direction MAC destino A e identificador de protocolo (Ethertype) el asignado al protocolo TCP-Path, y lo reenvia en unidifusion por el puerto asociado a la tupla AC, previamente asociada a dicho puerto cuando se recibio el paquete PathRequest. A su vez, el puente asocia (aprende) la direction MAC de C, la direction MAC de A, el puerto de transpose de C y el puerto de transpose de A al puerto por donde se ha recibido, identificados como la tupla {C,A,pC,pA} (abreviadamente, tupla CA) , asociandolos al identificador de caducidad anteriormente creado de la tupla AC, actualizando el tiempo de llegada, confirmando y renovando la validez de la asociacion.. En cada puente atravesado se asocia igualmente el puerto de reception a dicha tupla CA y se reenvia por el puerto asociado a la tupla AC, asociada a la conexion desde C hacia el terminal A, confirmando y renovando el camino en direction hacia A , asociandolos al identificador de caducidad anteriormente creado de la tupla AC, actualizando el tiempo de llegada, confirmando y renovando la validez de la asociacion..

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

El paquete PathReply Mega finalmente en unidifusion hasta el puente frontera de destino, al cual esta conectado directamente el terminal destino A. El puente desencapsula la trama conteniendo el segmento original SYN+ACK y la reenvia al terminal A. El terminal A respondera con una trama conteniendo un segmento de transpose con el indicador ACK activado, el cual sera 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 conexion. De la misma forma seran encaminados los sucesivos segmentos de datos enviados del terminal Aal C.

El protocolo TCP-Path encapsula los segmentos de transpose 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 altemativos 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

5

10

15

20

25

30

solamente a la direction MAC A o como camino bidirectional Flow-Path asociado a las direcciones A y C, la diferencia radica en que TCP-Path solo establece un camino nuevo asociado a la conexion si no existe camino previo entre A y C o, si existiendo, este es diferente del que esta 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 partial, completamente, o en absolute coincidir con los caminos preexistentes. Solo habra un camino entre A y C establecido por ARP-Path y Flow-Path, mientras que TCP-Path puede creartantos caminos adicionales como conexiones de transporte existan en cada momento.

Los caminos establecidos se refrescan, prolongando su validez, automaticamente al recibirse tramas del flujo asociado al camino. Este refresco puede ser hacia delante y opcionalmente bidirectional, segun se configure. En el refresco hacia delante las tramas retibidas renuevan la asociacion de la MAC destino de la trama reenviada al puerto de salida. En el bidirectional renuevan tambien la asociacion de la direction 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 reenvio) durante un tiempo superior al temporizador de persistencia (cache) de los puentes, expiran automaticamente, borrandose de la memoria los puertos asociados al camino.

Asimismo, cuando un camino establecido se interrumpe, porfallo de un enlace o de puente, se produce el borrado inmediato de las direcciones aprendidas en el puerto, asociadas en la tabla de reenvio al puerto conectado al enlace o puente en fallo.

De manera similar al establecimiento, los caminos TCP-Path pueden ser borrados explicitamente por los terminates cuando envian un segmento FIN en cada direction para cerrar la conexion TCP. Un terminal enviara un segmento FIN que es respondido por el terminal destino con un segmento ACK. Este segmento FIN cerrara la conexion TCP-Path en el sentido del segmento FIN enviado. Igualmente sucedera desde el extremo remote cuando se emita un segmento FIN contestado con un segmento ACK hacia el extremo remote para cerrar la conexion en el sentido remoto-cercano. Altemativamente, el extremo

5

10

15

20

25

30

receptor puede contestar con un segmento combinado FIN+ACK (el denominado cierre TCP de tres vias), que sera contestado con un segmento ACK para confirmar el cierre en el sentido remoto-cercano. Este segmento ACK no se encapsula.

Mas 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 unidifusion hacia el destino siguiendo el camino establecido por CA, para asi borrar el camino de A hacia C asociado a esa conexion TCP. El siguiente puente atravesado, al recibir dicha trama de unidifusion PathFlush con el campo de tipo de protocolo, conteniendo el valor asignado al protocolo "TCP-Path", borra de la tabla, a efectos de reenvio, la asociacion de direccion MAC destino y puerto de transpose destino al puerto del puente y el contenido del temporizador de caducidad asociado, sin modificar otras asociaciones de dicha direccion MAC a otros puertos del puente; comprueba asimismo si la direccion 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 reenvia al terminal destino por el puerto del puente asociado a dicho terminal. Si la direccion MAC destino de la trama encapsulada no esta asociada a un terminal conectado directamente al puente que recibe la trama, el puente reenvia la trama PathFlush en unidifusion por el puerto asociado a los "campos de la conexion TCP" recien borrados.

Reenvio de tramas

Cuando una trama de datos se recibe en un puente TCP-Path, se consultan los campos de conexion TCP: direcciones MAC origen y destino, puertos de transporte de origen y destino, y se verifica si existe un puerto asociado a dicha conexion como destino; si existe, se reenvia la trama por el puerto asociado a dicha conexion hacia el terminal destino y se renueva por un periodo adicional el temporizador asociado a la direccion MAC destino y conexion TCP-Path asociada; si no existe, se comprueba, de forma menos restrictiva, si existe algun puerto del puente asociado a la direccion MAC destino de la trama o al par direccion MAC destino y MAC origen de la trama; si existe se reenvia la trama por dicho puerto; en los demas casos se iniciara el proceso de reparation de caminos mediante el envio de una trama de multidifusion. Es decir, cuando no existe un camino especifico TCP- Path, puede ser utilizado por las tramas recibidas otro camino especifico TCP-Path destinado a la misma direccion MAC destino o bien un camino generico asociado

5

10

15

20

25

30

solamente a dicha direccion MAC (creado mediante ARP-Path o Flow-Path). Si no hay camino generico activo, uno de los caminos especificos TCP-Path pasara a ser generico, asociandolo a la direccion MAC destino, para ser utilizado por todas las tramas con ese destino.

Si no existe ningun camino generico, se repara el camino generico con la reparation habitual de ARP-Path o Flow-Path descrita en [Elisa Rojas, Guillermo Ibanez, 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].

Puente de red para caminos TCP-path

Los mecanismos de establecimiento de caminos, borrado de caminos y reenvio 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.

DESCRIPCION BREVE DE LOS DIBUJOS

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

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

La figura 3 muestra la busqueda de un camino TCP-Path tras la recepcidn de un segmento de transporte TCP con SYN activado (PathRequest).

La figura 4 muestra la confirmation 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 vias) emitido por el terminal A como respuesta al SYN+ACK reenviado por el nuevo camino TCP-Path establecido.

5

10

15

20

25

30

La figura 6 muestra un caso en que no se crea ningun camino adicional TCP-Path en la red porque el camino generico ARP-Path preexistente es el mas rapido.

La figura 7 muestra el caso en que se crea un camino adicional TCP-Path nuevo totalmente disjunto del camino generico 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 REALIZACION

Se describe un modo de realizacion de la invention. La figura 1 muestra la logica 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 transpose con los flags SYN o FIN activados, encapsulandose en el correspondiente paquete PathRequest (SYN), PathReply (SYN+ACK) o PathFlush (FIN) de ser asi. 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 logica de TCP-Path. Por ultimo, si no es ninguno de los anteriores casos, se utiliza la logica de funcionamiento de los protocolos ARP-Path y Flow-Path generica.

En la figura 2 se muestra una red de ejemplo para examinar el mecanismo de aprendizaje, borrado y reparation de TCP-Path. Los terminates A, B y C estan 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 direccion MAC origen de los paquetes ARP Request y ARP Reply emitidos por dichos terminates al comenzara comunicarse. Se indica con un circulo rodeando una letra junto a cada puente, el puerto al que esta asociada la direccion de dicho terminal (direccion aprendida). Por ejemplo, el camino hacia A esta 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 asi

5

10

15

20

25

30

la direction de las tramas en caso de haber trafico de comunicacion entre los terminales A y C. Los temporizadores de caducidad de cada tupla asociada al puerto estan activados y vigentes al no haber transcurrido el tiempo li'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. Asi pues, todos los puentes reciben una copia de la trama y apuntan la tupla AC (camino hatia 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, solo los puentes 1, 2 y 3 tenian un camino previo hacia A, por lo que el puente 3 aprende la tupla 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 descartara al haber sido recibida por el mismo puerto que la actual entrada de A que es por el puerto por el cual esta conectado al puente 1.

A continuation, 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 PathReply. Esta trama se reenvia en unidifusion por el puerto asotiado a la tupla previamente aprendida AC, es detir, se encamina a traves de los puentes 3, 4 y 1. En los puentes 4 y 1 se aprende la tupla CA (camino hacia C) porque no hay ninguna entrada generica 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 ultima parte del inicio de conexibn TCP, que es un segmento de transporte con el flag ACK activo. Este ultimo 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 trafico de dicha conexion recien iniciada, encaminandolo por los puertos asociados a la tupla CA y pasando por los puentes 1,4 y 3, hasta llegar a C. Notese que en el puente 3 no existe una entrada asociada a la tupla CA por ser el puente frontera de C, por lo que se utiliza la entrada generica C para encaminar, aprendida en el primer paso por el protocolo ARP-Path.

5

10

15

20

25

30

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 direccion, atravesando ambos los puentes 1,2 y 3, y ademas los caminos AC y CA creados por TCP- Path tambien. En la practica lo que sucederia en este caso es que las tuplas AC y CA no se anotarian, al coincidir con los puertos de las entradas genericas A y C ya existentes, por lo que no habria camino altemativo, situation que puede darse en caso de que el camino 1, 2 y 3 siga siendo el camino mas rapido y no este muy utilizado todavia. En el caso de la figura 7 se muestra el extremo contrario, aquel en el que los caminos genericos de ARP- Path A y C no comparten puentes (salvo los puentes frontera 1 y 3), y ademas el camino TCP-Path entre A y C atraviesa tambien puentes diferentes (pasando por el puente 4). Este ultimo caso podria darse cuando todos los caminos son igual de rapidos y se distribuirian por igual por toda la red. Notese que los caminos TCP-Path son simetricos, 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 genericos ARP-Path no tienen por que serlo.

Las figuras 8, 9 y 10 muestran el borrado de las entradas AC y CA mediante las tramas AllPath de tipo PathFlush. Estas tramas se crean al encapsular segmentos de transpose que contengan el flag FIN activo (ya sean FIN o FIN+ACK). En la figura 8 se envia 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 como quedaria la red tras el borrado de los caminos TCP-Path en las figuras anteriores mediante la trama PathFlush.

En la figura 11 podemos ver que significa cada circulo (A, C, AC o CA), es decir, cada una de las entradas en tabla de un puente que funcione siguiendo la especificacion de TCP- Path. La figura 11 .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 busqueda (en este caso la direccion 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 apuntara su clave dentro de la tabla tal y como muestra 11 .b). Es decir, la entrada con clave A sera la entrada generica para alcanzar el destino A, mientras que AC-* sera la clave concreta del camino de TCP-Path con destino A, pero que solo se utilizara cuando el

origen sea C y se cumplan otra serie de parametros (especificados con *) como pueden ser numeros de puertos, etc. Con la respuesta de C hacia A, SYN+ACK encapsulado en un mensaje PathReply, si esta llega por un puerto diferente al ya asociado a C, se realizara un aprendizaje analogo (figura 11 .c).

5

Por lo tanto, ademas del camino base, se crearan caminos adicionales con claves mas concretas, mientras que el resto de entradas de la tabla seran analogas.

Por otro lado, cuando llegue una trama de datos con destino A, se realizaran ahora dos 10 busquedas, una especifica de clave y otra generica si no se encontro la primera. Pero a su vez, si el camino especifico si existia y se borro por un fallo de enlace, esto garantiza que seguira siendo posible el uso del camino base, o generico, para el encaminamiento.

Claims (5)

1. 5

   10

   15

   20

   25

   30

   REIVINDICACIONES

   1. Procedimiento de establecimiento de caminos, reenvio de tramas y borrado de caminos de tramas de datos que comprende:

   - recibir, a traves de un puerto de un puente de red donde dicho puerto tiene una identidad de puerto asignada, una trama que comprende una direccion MAC origen y una direccion de difusion destino;

   - asociar, en una tabla, a efectos de reenvio del puente, la direccion MAC origen de la trama recibida a la identidad del puerto que primero recibio la trama en dicho puente, a un indicador de caducidad de dicha asociacion y al instante de llegada de la trama;

   - bloquear esta asociacion durante un tiempo determinado, impidiendo la asociacion de dicha direccion origen a otro puerto del puente;

   - descartar las tramas recibidas por puertos distintos al asociado a la direccion origen de la trama durante el tiempo en que este bloqueada esa asociacion;

   - reenviar las tramas unidifusion recibidas por el puerto del puente que este asociado a la direccion MAC destino de la trama

   - borrar, en la tabla, a efectos de reenvio, las asociaciones de direcciones que tenga un puerto de un puente cuando detecte la caida de un enlace en dicho puerto o expire el temporizador de validez de la direccion;

   - solicitar la reparation del camino mediante una trama de multidifusion cuando una trama con destino unidifusion llega a un puente que no tiene ningun puerto asociado en la tabla, a efectos de reenvio para dicha direccion 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

   conexion SYN activado y el indicador ACK desactivado,

   - crear una nueva conexion, asignandole un identificador intemo unico de conexion TCP-Path y asociar dicho identificador a la combination exacta de los campos siguientes contenidos en la trama que transporta el segmento TCP: direccion MAC origen, direccion MAC destino de la trama que

   5

   10

   15

   20

   25

   30

   transporta el segmento TCP y puertos de transporte TCP origen y destino de la cabecera del segmento TCP, en lo sucesivo “campos de la conexion TCP”;

   - asociar, en una tabla, a efectos de reenvio, las direcciones MAC origen y Puerto TCP origen, asi como el identificador de la conexion TCP-Path, a la identidad del puerto del puente que primero recibio 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 multidifusion PathRequest con direccion destino la direccion de grupo multicast compartida por “todos los puentes TCP-Path” y con direccion origen la direccion MAC del puente que encapsula la trama.

   -La existencia de una etapa de confirmacibn y renovacibn, en la que, al recibir en un puente de red una trama conteniendo un segmento TCP con el indicador de solicitud de conexibn SYN activado y el indicador ACK activado (segmento SYN- ACK),

   - confirmar y renovar la conexion, en la tabla, a efectos de reenvio, renovando durante un tiempo determinado la vigencia de la asociacion, creada previamente en el puente al recibirse el paquete PathRequest, de los “campos de la conexion 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 conexion, con la identidad del puerto del puente que primero recibio 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 SYN-ACK dentro de una trama especial de unidifusibn Path Re ply, con direccion MAC origen la del puente que la encapsula y destino la direccion MAC del puente que fue asociado en el puente a dicha conexion tras la recepcion del PathRequest para dicha conexion.

   -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 conexion FIN activado;

   5

   10

   15

   20

   25

   30

   - encapsular el segmento TCP dentro de una trama especial de unidifusion PathFlush dirigida al puente frontera destino por el puerto asociado a la direccion 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 reenvio, la asociacion de los “campos de la conexion 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 conexion existente en el puente consultando los campos de conexion 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 conexion hacia el terminal destino y renovar el temporizador asociado a la direccion MAC destino;

   - en los demas casos: si existe un camino especifico TCP-Path asociado a la direccion MAC destino pero vinculado a un puerto del puente distinto al puerto en fallo, reenviar dicha trama por dicho puerto de salida.

   - en los demas casos: comprobar si existe algun puerto del puente asociado a la direccion MAC destino de la trama;

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

   - en los demas casos: enviar una trama multidifusion para iniciar el mecanismo de reparation de caminos.
2. 2. Procedimiento segun la revindication 1, caracterizado por, en la etapa de establecimiento, al recibir en un puente de red una trama de multidifusion PathRequest dirigida a la direccion de grupo de multidifusion “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 reenvio, 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 conexion

   5

   10

   15

   20

   25

   30

   TCP”) a la identidad del puerto del puente que primero red bio la trama, a un indicador de caduddad de la trama y al instante de llegada de la trama;

   - asodar, en una tabla, a efectos de reenvio, la direccion MAC origen de la trama Path Request a la identidad del puerto del puente que primero recibio la trama;

   - comprobar si la direcdon 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 demas casos: reenviar la trama por todos los puertos excepto el puerto donde se recibio primero;

   - encolarla en las colas de salida de los puertos del puente segun criterios de prioridad configurados previamente.
3. 3. Procedimiento, segun la reivindicacion 1, caracterizado por, en la etapa de confirmation y renovation, al recibir en un puente de red una trama de unidifusion PathReply con destino una direccion 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 reenvio, las direcciones MAC origen y destino e identidades de puertos de transpose origen y destino de la trama original encapsulada dentro de la trama recibida (“campos de la conexion TCP”), a la identidad del puerto del puente que primero recibio la trama, a un indicador de caducidad de la trama y al instante de llegada de la trama;

   - comprobar si la direccion MAC destino, del encapsulado exterior de la trama corresponde al puente que esta 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 demas casos: reenviar la trama por el puerto asociado a las direcciones MAC origen y destino y puertos de transpose origen y destino de la conexion TCP-Path y renovar la asociacion de los “campos de la conexion TCP” al puerto de reenvio.
4. 4. Procedimiento segun la reivindicacion 1, caracterizado por, en la etapa de borrado, al recibir en un puente de red una trama de unidifusion 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 reenvio, la asociacion de los “campos de la conexion

   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 esten vinculadas a los puertos origen y destino indicados;

   - comprobar si la direction 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 demas casos: reenviar la trama PathFlush en unidifusion por el puerto

   15 asociado a los “campos de la conexion TCP” recien borrados.
5. 5. Puente de red caracterizado porque dispone de los medios de procesamiento apropiados para implementar el procedimiento de las reivindicaciones 1 a 4.

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

   puente de red definido segun la reivindicacion 5.