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

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.

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

Solicitante: UNIVERSIDAD DE ALCALA..

Nacionalidad solicitante: España.

Inventor/es: AZCORRA SALOÑA,ARTURO, ROJAS SÁNCHEZ,Elisa, MARTÍNEZ YELMO,Isaías, IBÁÑEZ FERNÁNDEZ,Guilermo.

Fecha de Publicación: .

Clasificación Internacional de Patentes:

  • H04L12/24 ELECTRICIDAD.H04 TECNICA DE LAS COMUNICACIONES ELECTRICAS.H04L TRANSMISION DE INFORMACION DIGITAL, p. ej. COMUNICACION TELEGRAFICA (disposiciones comunes a las comunicaciones telegráficas y telefónicas H04M). › H04L 12/00 Redes de datos de conmutación (interconexión o transferencia de información o de otras señales entre memorias, dispositivos de entrada/salida o unidades de tratamiento G06F 13/00). › Disposiciones para el mantenimiento o la gestión.
PROCEDIMIENTO DE ESTABLECIMIENTO Y BORRADO DE CAMINOS Y DE REENVIO DE TRAMAS PARA CONEXIONES DE TRANSPORTE Y PUENTE DE RED.

Fragmento de la descripción:

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 discover y 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,...

 


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.

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

-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 unidifusión 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.

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

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

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

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.

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

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. Nº solicitud28/11/2014F.OEPM28/11/2014F.EfectivaNº solicitud28/11/2014F.OEPM28/11/2014F.EfectivaNº solicitud28/11/2014F.OEPM28/11/2014F.EfectivaNº solicitud28/11/2014F.OEPM28/11/2014F.EfectivaNº solicitud28/11/2014F.OEPM28/11/2014F.EfectivaNº solicitud28/11/2014F.OEPM28/11/2014F.EfectivaNº solicitud28/11/2014F.OEPM28/11/2014F.EfectivaNº solicitud28/11/2014F.OEPM28/11/2014F.EfectivaNº solicitud28/11/2014F.OEPM28/11/2014F.EfectivaNº solicitud28/11/2014F.OEPM28/11/2014F.EfectivaNº solicitud28/11/2014F.OEPM28/11/2014F.Efectiva

 

Patentes similares o relacionadas:

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

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

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

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

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

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

Método para la gestión mejorada de llamadas de emergencia en un escenario de itinerancia y sistema, programa informático y medio legible por ordenador correspondientes, del 17 de Junio de 2020, de DEUTSCHE TELEKOM AG: Un método para la gestión mejorada de llamadas de emergencia en un escenario de itinerancia, en donde un equipo de usuario se asigna a una red de telecomunicaciones […]

Sistema y procedimiento de gestión móvil para gestionar una red de área local, del 10 de Junio de 2020, de Arcadyan Technology Corporation: Procedimiento de gestión móvil para gestionar una red de área local, que comprende: mientras se ejecuta un programa de gestión en un dispositivo móvil , activar una […]

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