ES2930669T3 - Procedimiento de comunicación TCP a través de múltiples rutas entre dos terminales - Google Patents

Procedimiento de comunicación TCP a través de múltiples rutas entre dos terminales Download PDF

Info

Publication number
ES2930669T3
ES2930669T3 ES15759497T ES15759497T ES2930669T3 ES 2930669 T3 ES2930669 T3 ES 2930669T3 ES 15759497 T ES15759497 T ES 15759497T ES 15759497 T ES15759497 T ES 15759497T ES 2930669 T3 ES2930669 T3 ES 2930669T3
Authority
ES
Spain
Prior art keywords
multipath
tcp
server
client device
connection
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES15759497T
Other languages
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Application granted granted Critical
Publication of ES2930669T3 publication Critical patent/ES2930669T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

La presente invención se refiere a un método de comunicación en una red IP, que incluye los siguientes pasos: descubrimiento (E1), por un dispositivo de comunicación (T, T1, T2, T3, R) capaz de implementar una conexión TCP simple (Transmission Control Protocol) y de implementar una conexión TCP multicamino, al menos un servidor de verificación (CHECK SERVER) capaz de implementar una conexión TCP multicamino; intentar establecer (E2), por dicho dispositivo comunicador (T, T1, T2, T3, R) y por dicho servidor de cheques (CHECK SERVER), respectivamente, al menos una conexión TCP multicamino con el servidor de cheques (CHECK SERVER) y con el dispositivo comunicador (T, T1, T2, T3, R), respectivamente, a través de al menos un camino que permite llegar al dispositivo comunicador (T, T1, T2, T3, R); y guardado (E3), por el dispositivo comunicante (T, T1, T2, T3, R), el estado (PATH CHECKED) de dicho camino en cuanto a la compatibilidad del mismo con conexiones TCP multicamino. La invención es útil en el protocolo MPTCP (Multipath TCP). (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Procedimiento de comunicación TCP a través de múltiples rutas entre dos terminales
La presente invención se refiere al campo de las telecomunicaciones, y especialmente a las redes de comunicaciones capaces de implementar el protocolo IP (Internet Protocol). Más particularmente, la presente invención se refiere a la prestación de servicios en las redes IP «con valor agregado», es decir las redes capaces de efectuar procesamientos diferenciados según la naturaleza del tráfico de datos enrutado en la red.
La invención se aplica a cualquier tipo de dispositivo cliente, tal como un terminal fijo o móvil, o una puerta de enlace doméstica, («Residential Gateway» en inglés), o una puerta de enlace ubicada en una empresa, o una puerta de enlace de operador de red («Gateway» en inglés), o incluso un decodificador de TV («Set-Top Box», o STB en inglés). Por razones de brevedad, un dispositivo cliente de cualquier tipo a menudo se denominará en lo sucesivo «terminal».
Los terminales, tales como los teléfonos inteligentes («smartphone» en inglés) y los ordenadores personales («Personal Computer», o PC en inglés) ahora son capaces de activar y utilizar varias interfaces lógicas vinculadas a una o varias interfaces físicas. Tales terminales se denominan «múltiples interfaces» («Multi-Interface», o MIF en inglés). Cuando un terminal dispone de varias interfaces capaces de conectarlo a diferentes redes de acceso (por ejemplo: fija, móvil, o WLAN), entonces se beneficia de un acceso denominado «híbrido», ya que combina diferentes tecnologías de redes de acceso.
A continuación, se pueden asignar varias direcciones IP a estos terminales MIF para que puedan conectarse a diferentes tipos de redes, tales como una red fija, una red móvil o una red WLAN (iniciales de las palabras en inglés «Wireless Local Area Network» que significan «Red Local Inalámbrica», cuyas redes Wi-Fi son un ejemplo emblemático), de manera simultánea o diferida. Estas direcciones IP pueden:
• pertenecer a la misma familia de direcciones o a familias de direcciones distintas (IPv4, IPv6 o las dos),
• tener vidas útiles diferentes,
• tener diferentes alcances, por ejemplo, dirección IPv4 privada, dirección IPv6 única de alcance local (Unique Local Address, o ULA en inglés), o dirección IPv6 de alcance global (Global Unicast Address, o GUA en inglés), y
• ser asignadas a la misma interfaz de red lógica o a diferentes interfaces de red lógica.
Sin embargo, cabe señalar que la característica «MIF» es volátil, ya que la capacidad de utilizar varias interfaces depende de las condiciones de conexión a la(s) red(es), la ubicación del dispositivo, u otros factores. Un dispositivo MIF puede, especialmente, utilizar la pluralidad de interfaces de las cuales dispone durante el establecimiento de una conexión simple (es decir, una conexión establecida a lo largo de una ruta única con un corresponsal dado), o incluso después del establecimiento de una conexión simple. También cabe señalar que un dispositivo no sabe a priori si es posible utilizar varias rutas distintas para establecer una conexión con un corresponsal dado; más precisamente, el dispositivo adquiere esta información (en caso necesario) solo después de una fase a lo largo de la cual intenta establecer una conexión que utiliza múltiples rutas con el corresponsal.
Se recuerda que una «conexión de múltiples rutas» es una conexión establecida entre dos dispositivos que utilice de manera simultánea una o más rutas entre estos dos dispositivos. Una tal conexión obedece a un protocolo dedicado, tal como MPTCP (Multi-Path TCP), que de manera eventual puede ser definido como una extensión de un protocolo de transporte previamente definido, tal como TCP (iniciales de las palabras en inglés «Transmission Control Protocol» que significan «Protocolo de Control de Transmisión»). En otras palabras, una conexión de múltiples rutas es un agregado de una o más conexiones simples que utilizan una misma ruta o rutas diferentes (de manera parcial o completamente disjuntas).
También se recuerda que el protocolo TCP, definido especialmente en la especificación RFC 793 del IETF (Internet Engineering Task Force), es uno de los principales protocolos utilizados por los terminales conectados a una red IP (por ejemplo, Internet), de modo que la literatura a menudo se refiere al conjunto de protocolos «TCP/IP». El protocolo TCP permite enrutar de manera fiable, ordenada y sin errores un flujo de datos digitales entre las aplicaciones ejecutadas en terminales conectados a una red local (por ejemplo, Intranet) o al Internet. Funciona al nivel de la capa de transporte del modelo OSI. Los navegadores Web utilizan el protocolo TCP cuando se conectan a servidores remotos; el protocolo TCP también se utiliza para enrutar el correo electrónico o para transferir archivos de un lugar a otro. Los protocolos como HTTP, HTTPS, s Mt P, POP3, IMAP, SSH, FTP, Telnet, así como muchos otros protocolos son transportados en las conexiones TCP. Una conexión TCP se identifica por la dirección y el número de puerto del terminal de origen, así como la dirección y el número de puerto del terminal de destino.
Dos terminales pueden insertar «opciones TCP» en los mensajes TCP intercambiados entre ellos, con el fin de, por ejemplo, optimizar la calidad de la transmisión TCP. Tales opciones ocupan el espacio disponible al final de la cabecera TCP, y tienen una longitud («length» en inglés) expresada en bytes. El tipo («kind» en inglés) de opción es un identificador único que describe la naturaleza de la opción TCP. Por ejemplo, el valor «0» indica el final de la lista de opciones, y el valor «2» indica el tamaño máximo del segmento TCP («Maximum Segment Size», o MSS en inglés).
La llegada de los terminales MIF introduce una complejidad adicional para utilizar la totalidad o parte de las direcciones IP asignadas a través de las redes disponibles. Siendo especialmente determinado, que las conexiones TCP están asociadas a una dirección IP y a un número de puerto, cualquier modificación de al menos una de estas informaciones es probable que penalice el funcionamiento de una conexión TCP en curso y, por tanto, el servicio que utiliza la dicha conexión TCP. Este cambio es particularmente perjudicial cuando se le asigna al terminal una nueva dirección IP, o porque el terminal se conecta a otra red, o incluso cuando la interfaz a la cual está asociada la dirección IP ya no está disponible. Por ejemplo, los medios para informar a un corresponsal TCP remoto que una dirección IP ya no es válida son entonces necesarios para asegurar el mantenimiento de una conexión existente.
El grupo de trabajo mptcp del IETF fue encargado en 2009 de especificar extensiones del protocolo TCP capaces de adaptarse a las restricciones impuestas por la posibilidad de asignar varias direcciones IP a las diferentes interfaces lógicas o físicas de un terminal. Este grupo de trabajo publicó las primeras especificaciones del protocolo MPTCP (cf. A. Ford, C. Raiciu y M. Handley, «TCP Extensions for Multipath Operation with Múltiple Addresses», RFC 6824, enero de 2013), que determinados teléfonos inteligentes y sistemas operativos ya son capaces de implementar. El IETF considera mejorar el estado de las especificaciones MPTCP actuales, para convertirlas en auténticos estándares en el sentido del IETF.
Por lo tanto, el protocolo MPTCP ha sido propuesto para minimizar los riesgos de una ruptura intempestiva de una conexión TCP vinculada a tales modificaciones de direccionamiento y, de manera más general, para responder a las exigencias planteadas por un contexto en el que un terminal tiene la capacidad de conectarse a una o más redes a través de una o más interfaces. El protocolo MPTCP responde, especialmente, a la necesidad de asegurar una continuidad de la sesión en caso de movilidad del terminal. Se pueden considerar diferentes casos de uso para el protocolo MPTCP, tales como:
• transferir el tráfico entre varios puntos de acceso WLAN,
• descargar una red móvil, y desviar el tráfico hacia un punto de acceso WLAN,
• agregar varios enlaces de acceso,
• distribuir la carga entre varias rutas, y
• optimizar la utilización de los recursos de red.
Se recuerda a este respecto (cf. Wikipedia) que «la agregación de enlaces» es, en el campo de las redes, un concepto que describe la agrupación de varias interfaces de red como si se tratara de una sola, con el objetivo de aumentar el rendimiento más allá de los límites de un solo enlace, y eventualmente para garantizar que otras interfaces tomen el relevo si falla un enlace de red (principio de redundancia).
Un ejemplo particularmente ventajoso de aplicación del protocolo MPTCP es la transferencia de archivos voluminosos que utilizan los recursos del protocolo FTP (File Transfer Protocol). Un dispositivo que actúe como cliente FTP puede utilizar de manera dinámica el conjunto de rutas disponibles el cual le permita acceder a un servidor FTP, siempre que este último sea capaz de implementar las diferentes conexiones MPTCP establecidas por el cliente FTP. Por tanto, el tiempo de transferencia de datos se reduce de manera significativa con respecto a una conexión TCP.
En el contexto de MPTCP, se denomina «subsesión» («sub-flow» en inglés) una conexión TCP que se basa en la utilización de uno de los pares (dirección IP, número de puerto) disponibles. Por lo tanto, una conexión MPTCP es un agregado de subsesiones TCP. A título de ejemplo, la figura 1 muestra una conexión MPTCP entre un terminal A y un terminal B; la subsesión inicial se establece entre la dirección A1 del terminal A y la dirección B1 del terminal B; posteriormente, se establece una subsesión adicional entre la dirección A2 del terminal A y la dirección B1 del terminal B.
Los sistemas operativos presentan a las aplicaciones de interfaces dedicadas, denominadas API (Application Programming Interface) para interactuar con las capas TCP e IP. La API convencional presentada a las aplicaciones TCP/IP es la interfaz «socket». Un «socket» se caracteriza por varios «atributos» tales como «Local Socket Address», «Remote Socket Address» y «Protocol». El IETF ha especificado nuevas extensiones (API de MPTCP) en el documento RFC 6897 para permitir que las aplicaciones controlen las conexiones MPTCP. Cabe señalar que la API de MPTCP es una extensión de la a Pi de TCP.
Se denomina «tabla de conexión MPTCP» a una estructura de software utilizada para agrupar todas las subsesiones TCP asociadas a una misma conexión MPTCP. Se pueden utilizar varios atributos para caracterizar una tabla de conexión MPTCP. Además de los atributos TCP/IP convencionales mencionados más arriba, se proporciona un valor a los atributos específicos del protocolo MPTCP. El valor de estos atributos de la tabla de conexión se controla a través de la API de MPTCP.
Una conexión MPTCP se inicializa como cualquier conexión TCP convencional, excepto que la opción TCP «MP_CAPABLE» (que significa que el terminal emisor es compatible con el protocolo MPTCP) se incluye en el mensaje que contiene el indicador de inicialización de conexión (SYN) y en los mensajes posteriores. Un terminal MPTCP puede notificar al terminal remoto la disponibilidad de una dirección IP adicional con la ayuda de la opción TCP «ADD_ADDR», sin necesidad de crear una subsesión asociada.
Sin embargo, la señalización de varias direcciones IP disponibles y susceptibles de ser utilizadas para comunicarse con un corresponsal puede llevar al fracaso del establecimiento de determinadas subsesiones TCP debido a que las direcciones IP externas, tales como las percibidas por los terminales remotos pueden no ser las mismas que las visibles localmente. Por esta razón, la opción ADD_ADDR del protocolo MPTCP comprende un identificador de dirección («Address ID») utilizado para identificar de manera única una dirección IP disponible. Esta disposición se supone, según el estado de la técnica, para evitar los problemas inducidos por la presencia de un NAT (iniciales de las palabras en inglés «Network Address Translater» que significan «Traductor de Dirección de Red») en la ruta seguida por los paquetes entre los dos terminales los cuales han establecido una conexión MPTCP. La opción ADD_ADDR también se utiliza para transmitir un número de puerto en el caso de que uno de los terminales MPTCP no utilice el mismo número de puerto para el conjunto de direcciones IP disponibles.
De manera similar, el protocolo MPTCP prevé disposiciones las cuales se supone permiten, especialmente, el cruce de cortafuegos («cortafuegos» en inglés). Más precisamente, la especificación del protocolo MPTCP estípula que los números de secuencia, tales como los indicados en la cabecera t Cp son específicos para cada subsesión, mientras que el número de secuencia indicado en la opción TCP «DSS» («Data Sequence Signal») del protocolo MPTCP sirven para asociar estas subsesiones a la misma conexión MPTCP.
El protocolo MPTCP pretende superar las restricciones impuestas por la proliferación masiva de «middle boxes» (funciones de servicio insertadas en una cadena de comunicación), como los NAT y los cortafuegos, en las redes actuales. Además, en el documento RFC 6824 se prevé que en caso fallo de un intento de establecimiento de una conexión MPTCP, la conexión se transforma automáticamente en una conexión TCP simple.
El documento de D. Wing et al. publicado por el IETF y titulado «Multipath TCP (MPTCP) Path Selection using PCP; draf-wing-mptcp-pcp-00.txt», páginas 1-10, 7 de octubre de 2013, describe un protocolo que permite que una API de MPTCP seleccione una ruta cuando están múltiples rutas disponibles gracias a las extensiones PCP (Port Control Protocol).
El documento de A. Ford et al. publicado por el IETF y titulado «TCP Extensions for Multipath Operation with Multiple Addresses», páginas 1-64, enero de 2013, presenta un conjunto de extensiones en el protocolo TCP para admitir un funcionamiento con múltiples rutas.
El documento US 2011/296006 describe un procedimiento de comunicación inalámbrica que comprende una comunicación con un servidor a través de una primera ruta MPTP utilizando una primera dirección IP, una comunicación con el servidor a través de una segunda ruta MPTP utilizando una segunda dirección IP y por medio de un nodo inalámbrico y comunicación entre pares con el nodo inalámbrico.
Desafortunadamente, a pesar de todas estas precauciones, pueden surgir otros problemas durante el intento de establecimiento de una conexión MPTCP. Por ejemplo:
- algunas opciones del protocolo MPTCP, o incluso todas, pueden ser filtradas (es decir, retiradas) por funciones de servicio, tales como un NAT o un cortafuegos, ubicado en un corte de flujo entre dos pares MPTCP, como se ilustra en la figura 2 ;
- incluso si los mensajes SYN MPTCP (mencionados más arriba) se intercambian con éxito entre dos pares MPTCP, las funciones de servicio ubicadas en el corte de flujo entre los dos pares pueden filtrar las opciones DSS (mencionadas más arriba) de los paquetes de datos; en este caso, como se ilustra en la figura 3, el intento de establecimiento de una conexión MPTCP no puede tener éxito, con el repliegue como consecuencia en una conexión TCP simple como en el caso ilustrado con referencia a la figura 2 ;
- Puede generar que una primera subsesión TCP se establezca con éxito, pero que el establecimiento de subsesiones posteriores falle por falta existencia de otras rutas compatibles con el protocolo MPTCP.
Los autores de la presente invención se dieron cuenta de que, en estas condiciones, la presencia de tales funciones de servicio tenía el efecto de prolongar sustancialmente el retardo de establecimiento de subsesiones TCP y, en consecuencia, tenía un impacto negativo en la calidad del servicio de comunicación, tal como lo percibe el usuario.
Por lo tanto, la presente invención se refiere a un procedimiento de comunicación en una red IP según la reivindicación 1 implementado por un dispositivo cliente, un dispositivo cliente según la reivindicación 3, un procedimiento de comunicación en una red IP según la reivindicación 5, implementado por un dispositivo de retransmisión, un dispositivo de retransmisión según la reivindicación 6 , un medio de almacenamiento de datos según la reivindicación 8 y un programa de ordenador según la reivindicación 9.
Gracias a la invención, un dispositivo comunicante, el cual adopta la forma del dispositivo cliente de la reivindicación 3 o del dispositivo de retransmisión de la reivindicación 6, puede:
• descubrir las capacidades de eventuales funciones de servicio, tales como un NAT o un cortafuegos, ubicadas en el corte de flujo en una ruta que permita llegar a este dispositivo comunicante, especialmente, con el fin de establecer si una de estas funciones de servicio filtra o modifica las opciones TCP de múltiples rutas (en el contexto de la presente invención, se denomina «opción TCP de múltiples rutas» a una opción TCP definida por el protocolo de conexiones de múltiples rutas utilizado),
• registrar, en consecuencia, el estado de esta ruta, es decir, su compatibilidad o no compatibilidad con las conexiones de múltiples rutas, y
• antes de cualquier intento de conexión con un corresponsal dado, anticipar el fallo de una conexión TCP de múltiples rutas con este corresponsal a lo largo de una ruta determinada que vincula el dispositivo comunicante con este corresponsal.
Por lo tanto, el dispositivo comunicante sabrá de antemano, durante el establecimiento de una conexión con un corresponsal, si puede establecer una conexión de múltiples rutas a lo largo de esta ruta, o si deberá conformarse con una conexión TCP simple. El resultado es una reducción del retardo de establecimiento de la conexión y, por lo tanto, de manera evidente, una calidad de experiencia de usuario sustancialmente mejorada.
Los dispositivos comunicantes considerados por la invención pueden ser de cualquier tipo, por ejemplo, un terminal, un enrutador o una puerta de enlace residencial.
Además, un tal dispositivo comunicante puede:
• ajustar su comportamiento en función de su vinculación a la red (por ejemplo, en caso de vinculación a una nueva red, indisponibilidad de una interfaz de red, o detección de una función de servicio), y
• decidir, sin riesgo de degradar la calidad de la comunicación con su corresponsal, activar una conexión de múltiples rutas, o desactivar una conexión de múltiples rutas en curso o todas sus conexiones de múltiples rutas en curso, o incluso agregar una nueva subsesión TCP a una conexión de múltiples rutas en curso.
Gracias a la invención, tal como se reivindica, el dispositivo comunicante puede determinar de manera conveniente la compatibilidad o la no compatibilidad de la dicha ruta con las conexiones TCP de múltiples rutas.
La invención puede ser implementada por un dispositivo cliente que disponga de una o más direcciones externas, o de una o más interfaces de red (lógicas o físicas). Este dispositivo cliente también puede disponer de una sola interfaz si está ubicado detrás de un dispositivo de retransmisión (tal como un enrutador o una puerta de enlace residencial) conectado a una o más redes y compatible con las conexiones de múltiples rutas.
Gracias a la invención, se evita el retardo que podría provocar un intento de establecimiento de una conexión de múltiples rutas a lo largo de una ruta incompatible con una tal conexión.
Si un dispositivo cliente capaz de implementar una conexión TCP de múltiples rutas constata que al menos una de las rutas que permiten llegar a este dispositivo cliente es compatible con las conexiones TCP de múltiples rutas, el procedimiento comprende además una etapa a lo largo de la cual el dicho dispositivo cliente utiliza las opciones TCP de múltiples rutas para establecer conexiones con otro dispositivo cliente a lo largo de la dicha ruta compatible con las conexiones TCP de múltiples rutas.
En particular, los dos pares podrán establecer entre ellos una conexión de múltiples rutas a lo largo de una ruta previamente considerada como incompatible con una tal conexión, si han cambiado las circunstancias que anteriormente provocaron un repliegue a una conexión TCP simple.
Cabe señalar que la invención puede implementarse incluso cuando un dispositivo cliente conoce sólo una ruta para comunicarse con un corresponsal dado; se recuerda que la posible disponibilidad de múltiples rutas sólo se determina durante el establecimiento de una conexión con el corresponsal. De preferencia, la invención se implementará para cada una de las posibles rutas de comunicación entre los dos dispositivos clientes, después del descubrimiento de esta ruta por uno u otro de estos dispositivos cliente; por tanto, se beneficiará al máximo de las posibilidades ofrecidas por las conexiones de múltiples rutas.
Además, la dicha conexión de múltiples rutas puede estar ventajosamente de acuerdo con el protocolo MPTCP, de manera que se beneficie de las disposiciones de este protocolo, tal como se mencionó brevemente más arriba.
De manera correlativa, la invención se refiere a diversos dispositivos.
Por tanto, se refiere, en primer lugar, a un dispositivo comunicante que es, o bien un dispositivo cliente según la reivindicación 3, o un dispositivo de retransmisión según la reivindicación 6.
Además, este dispositivo cliente comprende además medios para:
- constatar que al menos una de las rutas que permiten llegar al dicho dispositivo cliente es compatible con las conexiones TCP de múltiples rutas, y
- utilizar opciones TCP de múltiples rutas para establecer conexiones con otro dispositivo cliente a lo largo de la dicha ruta compatible con las conexiones TCP de múltiples rutas.
Gracias a la invención, el dispositivo cliente al cual está conectado el dispositivo de retransmisión cambia sin retardo a una conexión TCP simple.
Las ventajas ofrecidas por estos dispositivos comunicantes son esencialmente las mismas que las ofrecidas por los procedimientos correlativos descritos brevemente más arriba.
En un modo de realización particular, el servidor de pruebas, al cual se hace referencia en las reivindicaciones independientes, posee medios para implementar una conexión TCP de múltiples rutas, así como medios para: - recibir una solicitud de establecimiento de una conexión TCP de múltiples rutas por parte de un dispositivo comunicante, e
- intentar establecer al menos una conexión TCP de múltiples rutas con el dicho dispositivo comunicante a lo largo de al menos una ruta de comunicación entre ellos.
El dicho servidor de prueba es notable porque los dichos medios para intentar establecer una conexión de múltiples rutas con el dispositivo comunicante comprenden medios para intercambiar datos de prueba con el dispositivo comunicante que permiten que el dispositivo comunicante determine si las opciones TCP de múltiples rutas enviadas por el dispositivo comunicante, respectivamente por el dicho servidor de prueba, son recibidas correctamente por el servidor de prueba, respectivamente por el dispositivo comunicante.
Las ventajas ofrecidas por este servidor de prueba son esencialmente las mismas que las ofrecidas por los procedimientos correlativos descritos brevemente más arriba.
Cabe señalar que es posible realizar estos diversos dispositivos en el contexto de instrucciones de software y/o en el contexto de circuitos electrónicos.
La invención también se refiere a un programa de ordenador descargable desde una red de comunicaciones y/o almacenado en un soporte legible por ordenador y/o ejecutable por un microprocesador. Este programa de ordenador es notable porque comprende instrucciones para la ejecución de las etapas del procedimiento de comunicación descrito brevemente más arriba, cuando se ejecuta en un ordenador.
Las ventajas ofrecidas por este programa de ordenador son esencialmente las mismas que las ofrecidas por el dicho procedimiento.
Otros aspectos y ventajas de la invención aparecerán con la lectura de la descripción detallada más abajo de modos de realización particulares, dados a título de ejemplos no limitativos. La descripción se refiere a las figuras adjuntas, en las cuales:
- la Figura 1, descrita más arriba, representa un agregado de subsesiones TCP que forman una única conexión MPTCP,
- la Figura 2, descrita más arriba, representa el fallo de un intento de establecimiento de una subsesión TCP al terminal B a partir de un terminal A, después del filtrado de opciones MPTCP por funciones de servicio,
- la Figura 3, descrita más arriba, representa el fallo de un intento de establecimiento de una subsesión TCP al terminal B a partir de un terminal A, después del filtrado de opciones DSS por funciones de servicio,
- la Figura 4 ilustra una configuración de red que comprende tres terminales T1, T2 y T3,
- la Figura 5 ilustra un procedimiento de prueba ejecutado por un terminal T1 con un servidor de prueba CHECK_SERVER_1, según un modo de realización de la invención,
- la Figura 6 ilustra un procedimiento de prueba ejecutado por un terminal T2 con un servidor de prueba CHECK_SERVER_2, según un modo de realización de la invención, y
- la Figura 7 ilustra la aplicación de un modo de realización de la invención a una configuración de red que comprende un terminal TCP o MPTCP, designado por T en la figura, colocado detrás de un dispositivo R de retransmisión compatible con MPTCP.
El descubrimiento de varias rutas que conectan un terminal dado con un corresponsal dado puede realizarse, por ejemplo, con la ayuda de un protocolo de asignación dinámica de direcciones IP como DHCP (Dynamic Host Configuration Protocol), o a través de un mecanismo de creación de mapping, tal como el PCP (Port Control Protocol), el UPnP (Universal Plug and Play), el IGD (Internet Gateway Device) o STUN (Session Traversai Utilities for NAT). Se recuerda a este respecto que se denomina «mapping» a la asociación de una dirección IP interna y de un número de puerto interno con una dirección IP externa y un número de puerto externo. En el caso de un NAT, la dirección IP interna y el número de puerto interno son las informaciones que sirven de datos de entrada, mientras que la dirección IP externa y el número de puerto externo son asignados por el NAT. En el caso de un cortafuegos, las informaciones internas y externas son idénticas. Un mapping puede incluir otras informaciones, tales como la dirección IP y el número de puerto del corresponsal o un identificador del protocolo de comunicación utilizado.
Cabe señalar que la invención puede ser implementada tanto por un primer dispositivo cliente como por un segundo dispositivo cliente con el cual el primer dispositivo cliente desea establecer una conexión de múltiples rutas, o solamente por uno de ellos; en este último caso, el otro dispositivo cliente puede implementar de manera eventual un procedimiento distinto del procedimiento según la invención para conocer la compatibilidad de las rutas que vinculan estos dos dispositivos cliente con las conexiones de múltiples rutas.
La invención propone un nuevo atributo por incluir en las tablas de conexión de múltiples rutas. Este atributo, que se denominará «PATH_CHECKED», está valorizado en «1» para indicar que una ruta es compatible con las conexiones de múltiples rutas, y valorizado en «0» en el caso contrario.
La invención también propone desplegar al menos un servidor de prueba (que se denominará «CHECK_SERVER») capaz de implementar la presente invención, y cuya función es, especialmente, ayudar a un terminal a determinar si las funciones de servicio (por ejemplo, NAT o cortafuegos) ubicadas en el corte de flujo en las rutas que permiten llegar a este terminal son compatibles con las conexiones de múltiples rutas. Cabe señalar que:
- este servidor de prueba es un dispositivo compatible con las conexiones de múltiples rutas;
- para este efecto, se pueden desplegar uno o más servidor(es) de prueba; en particular, no es obligatorio para todos los terminales solicitar un mismo servidor de prueba, y no es obligatorio para un terminal dado solicitar el mismo servidor de prueba a medida que evolucionan las condiciones de vinculación a la red de este terminal; y
- estos servidores de prueba no están necesariamente ubicados en el mismo dominio de red que el terminal; en otras palabras, un servidor de prueba puede estar ubicado en un dominio de red diferente al cual está conectado el terminal; por tanto, estos dos dominios de red pueden colocarse bajo la responsabilidad de gestión de dos entidades administrativas distintas, siempre y cuando esto no inhiba la capacidad del terminal para solicitar un tal servidor de prueba conectado a un dominio de red distinto al cual está conectado el terminal para cualificar la compatibilidad de las diversas múltiples rutas disponibles con el establecimiento de conexiones de múltiples rutas o de subsesiones TCP.
La invención se aplica de manera general a cualquier protocolo relacionado con las conexiones TCP de múltiples rutas. Ahora se describe la aplicación de la invención al protocolo MPTCP descrito brevemente más arriba. En particular, la API de MPTCP, mencionada más arriba, debe modificarse para que se pueda transmitir a las aplicaciones el valor del atributo PATH_CHECKED según la invención.
El protocolo MPTCP comprende de manera convencional un determinado número de disposiciones, incluida especialmente la definición de las siguientes opciones TCP:
• MP_CAPABLE: esta opción se utiliza para señalar al terminal remoto que el terminal emisor es compatible con las opciones de MPTCP;
• ADD_ADDR: esta opción se utiliza para agregar una nueva dirección; comprende un campo opcional de dos bytes que permite proporcionar también un número de puerto, en caso necesario;
• REMOVE_ADDR: esta opción se utiliza para eliminar una dirección;
• MP_PRIO: esta opción se utiliza para modificar la prioridad de una conexión;
• MP_JOIN: esta opción se utiliza para identificar la conexión TCP la cual está asociada al establecimiento de una nueva subsesión;
• MP_FAIL: esta opción se utiliza para volver al modo TCP sin opciones MPTCP; y
• MP_FASTCLOSE: esta opción se utiliza para cerrar rápidamente una conexión MPTCP.
El protocolo MPTCP puede ser activado según varios modos:
- modo nativo: dos terminales MPTCP establecen todas las subsesiones que corresponden a los números de direcciones/puertos disponibles, y utilizan el conjunto de estas subsesiones;
- modo primario: dos terminales MPTCP señalan subsesiones, pero solo un subconjunto de estas subsesiones es efectivamente utilizado para la transferencia de datos;
- modo secundario: en caso de indisponibilidad (o de sobrecarga) del subconjunto «primario» de subsesiones, se solicita entonces un subconjunto «secundario» de subsesiones para asegurar la continuidad de la conexión MPTCP; y
- modo repliegue: dos terminales MPTCP utilizan una única subsesión;
en caso de falla, el tráfico se cambia a una nueva subsesión creada para este efecto.
Ahora se describe un modo de realización del procedimiento de comunicación según la invención.
Este modo de realización puede implementarse, por ejemplo, al inicio de un terminal, o en cada cambio de las condiciones de vinculación de un terminal a la red (por ejemplo, vinculación a una nueva red), o incluso después de la detección a través de un terminal de una nueva ruta. Comprende una fase de prueba, cuyos resultados son, de preferencia, guardados en una caché local; el atributo PATH_CHECKED se puede utilizar para este efecto.
Durante una etapa E1, un terminal T descubre un servidor de prueba CHECK_SERVER:
- si se ha configurado explícitamente una dirección del servidor de prueba CHECK_SERVER en el terminal T, el terminal T utiliza esta dirección para contactar con el servidor de prueba;
- si no se configura explícitamente ninguna dirección en el terminal T, el terminal T utiliza una «dirección conocida» («Well-Known Address», o WKA, en inglés) de tipo anycast, o un «nombre de dominio conocido» («Well-Known Domain», o WKDN, en inglés), con el fin de simplificar las operaciones de configuración y descubrimiento de los servidores CHECK_SERVER a través de los terminales; se recuerda a este respecto que, en el modo de difusión de mensajes denominado «anycast», cada dirección de destino identifica un conjunto determinado de receptores, pero sólo uno de estos receptores es seleccionado para recibir un mensaje en un momento dado por parte de un emisor dado, siendo el receptor seleccionado en general aquel cuya distancia la cual lo separa del emisor es la más corta en el sentido del enrutamiento IP.
Durante una etapa E2, el terminal T ejecuta, para al menos una ruta que le permita llegar, un procedimiento de prueba de la dicha ruta con la ayuda de al menos un servidor CHECK_SERVER; como se mencionó más arriba, un terminal puede ejecutar este procedimiento de prueba, ya sea con un solo servidor CHECK_SERVER, o con varios servidores CHECK_SERVER con el fin de mejorar la calidad de las pruebas y la relevancia de los resultados.
El terminal T implementa este procedimiento de prueba, de preferencia, durante un reinicio del terminal, o durante cada vinculación a una nueva red, o incluso cuando se descubre una nueva ruta que permite llegar al terminal T.
Además, el terminal T implementa este procedimiento de prueba, de preferencia, para el conjunto de rutas conocidas del terminal T. El procedimiento de prueba de una pluralidad de rutas puede implementarse por separado (es decir, estableciendo tantas conexiones MPTCP como múltiples rutas disponibles), o colectivamente dentro de una sola conexión MPTCP (es decir, agregando subsesiones TCP a una conexión MPTCP principal, estas subsesiones corresponden a las múltiples rutas distintas a la utilizada para establecer la conexión MPTCP principal).
El procedimiento de prueba comprende la inicialización, a través del terminal T o a través del servidor CHECK_SERVER, de al menos una conexión MPTCP a lo largo de al menos una ruta de comunicación entre ellos. El terminal T y el servidor CHECK_SERVER intercambian datos de prueba con el fin de, al menos:
- determinar si las opciones TCP (especialmente las opciones DSS) enviadas por el terminal T (respectivamente, el servidor CHECK_s Er VER) son recibidas correctamente por el servidor CHECK_SERVER (respectivamente, el terminal T), y
- verificar el comportamiento de las funciones de servicio ubicadas en un corte de flujo en la dicha ruta con respecto al tratamiento de opciones MPTCP, y, en particular, determinar si las opciones MPTCP enviadas por el terminal T (respectivamente, el servidor CHECK_SERVER) son recibidas correctamente por el servidor CHECK_SERVER (respectivamente, el terminal T).
El terminal T puede, por ejemplo, concluir que el servidor CHECK_SERVER ha detectado una anomalía basándose en la observación de que el servidor CHECK_SERVER ha cambiado al modo TCP simple. El terminal T también puede detectar de manera local que al menos una de las rutas no es compatible con las comunicaciones MPTCP, especialmente cuando es el servidor CHECK_SERVER el cual ha inicializado una conexión MPTCP o una subsesión TCP.
Luego, durante una etapa E3:
- si no ha sido detectada ninguna anomalía por el terminal T o por un servidor CHECK_SERVER, el terminal T actualiza su tabla de múltiples rutas posicionando el atributo PATH_CHECKED en «1» para indicar que la dicha ruta es compatible con el modo comunicación de múltiples rutas;
- si, por el contrario, se ha detectado una anomalía por el terminal T o un servidor de prueba CHECK _SERVER, el terminal T actualiza su tabla de múltiples rutas posicionando el atributo PATH_CHECKED en «0» para indicar que esta ruta no es compatible con el modo de comunicación de múltiples rutas.
Después de la implementación de las anteriores etapas E1 a E3:
- si ninguna de las rutas que permiten llegar al terminal T es compatible con las conexiones MPTCP (es decir, si el atributo PATH_CHECKED de todas las múltiples rutas para todas las interfaces de red del terminal T está valorado en «0»):
O el terminal T utiliza el modo de transporte TCP simple para establecer conexiones salientes con sus corresponsales TCP (es decir, el modo TCP de múltiples rutas es desactivado por este terminal mientras que las condiciones de vinculación a la red no sean favorablemente modificadas), y
O para una conexión de múltiples rutas entrante, el terminal T no incluye opciones de MPTCP en sus mensajes destinados a su corresponsal (en otras palabras, el terminal se comporta como si no fuera compatible con MPTCP); después de la recepción de un tal mensaje sin opciones de MPTCP a través del corresponsal del terminal T, el corresponsal cambia sin retardo a una conexión TCP simple, de acuerdo con el convencional «modo de repliegue»; - si por el contrario existe al menos una ruta compatible con las conexiones MTPCP (es decir, si el atributo PATH_CHECKED de al menos una de las múltiples rutas está valorizado en «1»), el terminal T utiliza las opciones de MPTCP para establecer conexiones de múltiples rutas con un corresponsal a lo largo de la, o de las ruta(s) compatible(s); además, el terminal T se abstiene de anunciar a este corresponsal las eventuales rutas incompatibles con las conexiones MPTCP, de manera que evite el fallo de un intento de establecimiento de una conexión de múltiples rutas a lo largo de una ruta incompatible.
La figura 4 ilustra una configuración de red que comprende tres terminales T1, T2 y T3. Se observa en esta figura:
• un terminal T1 conectado a una o más red(es) IP a través de n nodos de conexión (F1, F2, ..., Fn) y n respectivas redes de acceso R1, R2, ..., Rn; estos nodos de conexión pueden alojar funciones de servicio, tales como un NAT o un cortafuegos, o ser enrutadores IP que no incorporan ninguna función de servicio, tal como un NAT o un cortafuegos;
• un terminal T2 conectado a una red IP a través de un solo nodo de conexión; se supone que T2 es compatible con MPTCP, y que se le ha asignado una dirección IP única; y
• un terminal T3 conectado a una o más red(es) IP a través de m nodos de conexión (Fa, Fb, ..., Fm); estos nodos pueden alojar funciones de servicio, tales como un NAT o un cortafuegos, o ser enrutadores IP que no incorporan ninguna función de servicio, tal como un NAT o un cortafuegos.
Se supone que, como se ilustra en la figura 5, el terminal T1 ha implementado, con el servidor CHECK _SERVER_1, el modo de realización de la invención descrito más arriba, y el cual ha concluido que:
o F1 filtra las opciones de MPTCP,
o F2 solo filtra las opciones de MPTCP de los paquetes de datos, y
o Fn no filtra ni modifica ninguna de las opciones de MPTCP.
También se supone que, como se ilustra en la figura 6 , el terminal T3 ha implementado, con el servidor CHECK_SERVER_2, el modo de realización de la invención descrito más arriba, y el cual ha concluido que:
o Fa filtra las opciones de MPTCP,
o Fb no filtra ni modifica ninguna de las opciones de MPTCP, y
o Fm no filtra ni modifica ninguna de las opciones de MPTCP.
Por tanto, las rutas MPTCP válidas entre T1 y T3 son las siguientes:
- la ruta que pasa a través de Fn y Fb, y
- la ruta que pasa a través de Fn y Fm.
Finalmente, se supone que el terminal T1 desea establecer una conexión MPTCP con el terminal T3. La figura 4 ilustra las subsesiones TCP establecidas entre los terminales T1 y T3.
El terminal T1 indica a su corresponsal el cual es compatible con las conexiones MPTCP, pero solo anuncia la ruta que implica Fn. El terminal T3 indica a su corresponsal que es compatible con las conexiones de múltiples rutas, pero solo anuncia los rutas que implican Fb y Fm. Por tanto, T1 y T3 pueden establecer:
- una subsesión TCP que implica Fn (lado T1) y Fb (lado T3), y
- una subsesión TCP que implica Fn (lado T1) y Fm (lado T3).
La figura 7 ilustra una aplicación de la invención con una configuración de red que comprende un terminal T compatible con TCP o MPTCP, colocado detrás de un dispositivo R de retransmisión (tal como un enrutador o una puerta de enlace residencial) compatible con MPTCP y capaz de implementar la presente invención.
Este dispositivo R de retransmisión está conectado a una o más redes IP a través de n nodos de conexión (F1, F2, ..., Fn) y n respectivas redes de acceso R1, R2, ..., Rn; estos nodos de conexión pueden alojar funciones de servicio, tales como un NAT o un cortafuegos, o ser enrutadores IP que no incorporan ninguna función de servicio, tal como un NAT o un cortafuegos.
Cabe señalar que, si el terminal T es compatible con MPTCP, puede implementar el presente modo de realización incluso en presencia del dispositivo R de retransmisión. En este caso, el dispositivo R de retransmisión procede como sigue.
En primer lugar, el terminal T ejecuta las etapas descritas más arriba. Por razones de simplificación, el dispositivo R de retransmisión puede estar presente ventajosamente en el terminal T (por ejemplo, mediante configuración explícita) tal como «su» servidor CHECK_SERVER; para realizar esto, es suficiente configurar el terminal T de manera que la dirección del servidor CHECK_SERVER sea la dirección del dispositivo R de retransmisión.
El dispositivo R de retransmisión intercepta entonces los mensajes de prueba enviados por el terminal T, y responde a cada uno de estos mensajes. Para realizar esto, procede como sigue:
a) si el dispositivo R de retransmisión ha ejecutado previamente un procedimiento de prueba similar al descrito más arriba con referencia a la etapa E2:
O si al menos una de las múltiples rutas conocidas por el dispositivo R de retransmisión es compatible con las conexiones MPTCP (es decir, si el atributo PATH_CHECKED de al menos una de las múltiples rutas está valorizado en «1»), el dispositivo R de retransmisión responde de manera positiva al terminal T, es decir le confirma al terminal T la capacidad de establecer conexiones MPTCP;
O si ninguna de las múltiples rutas conocidas del dispositivo R de retransmisión es compatible con las conexiones MPTCP (es decir, si el atributo PATH_CHECKED de todas las múltiples rutas está valorizado en «0»), el dispositivo R de retransmisión responde de manera negativa al terminal T, es decir indica al terminal T que no le será posible utilizar los recursos del protocolo MPTCP para establecer una conexión TCP con un corresponsal;
b) si el dispositivo R de retransmisión aún no ha ejecutado un procedimiento de prueba similar al descrito con referencia a la etapa E2, pone en espera el mensaje de prueba recibido por parte del terminal T, y ejecuta el procedimiento de prueba con un servidor de prueba remoto; una vez que se ha completado el procedimiento de prueba, el dispositivo R de retransmisión procede como se describe más arriba en a).
Cuando el terminal T inicializa una conexión TCP de múltiples rutas:
- el dispositivo R de retransmisión enruta los paquetes de datos utilizando la, o las ruta(s) cuyo atributo PATH_CHECKED está posicionado en «1»;
- si el dispositivo R de retransmisión no dispone de ninguna ruta, distinta que su conexión al terminal T, compatible con las conexiones MPTCP, y si recibe, sin embargo, un mensaje de inicialización de conexión de múltiples rutas por parte del terminal T, el dispositivo R de retransmisión no transmite este mensaje de inicialización a su destinatario; además, el dispositivo R de retransmisión responde al terminal T (haciéndose así pasar por el corresponsal del terminal T) no incluyendo ninguna opción MPTCP en su respuesta; Luego, T cambia sin retardo a una conexión TCP simple, de acuerdo con el convencional «modo de repliegue».
La invención se puede implementar dentro de los nodos de las redes de comunicaciones, por ejemplo, terminales, enrutadores o puertas de enlace, por medio de componentes de software y/o hardware.
Los componentes de software pueden estar integrados en un programa de ordenador convencional de gestión de nodos de red. Por esta razón, como se indicó más arriba, la presente invención también se refiere a un sistema informático. Este sistema informático incluye de manera convencional una unidad central de procesamiento controlada por las señales de una memoria, así como una unidad de entrada y una unidad de salida. Además, este sistema informático puede ser utilizado para ejecutar un programa de ordenador que comprenda instrucciones para la implementación de cualquiera de los procedimientos de comunicación según la invención.
En efecto, la invención también se refiere a un programa de ordenador, tal como se ha descrito brevemente más arriba. Este programa de ordenador puede ser almacenado en un soporte legible por ordenador y puede ser ejecutable por un microprocesador. Este programa puede utilizar cualquier lenguaje de programación, y presentarse en forma de código fuente, código objeto, o código intermedio entre el código fuente y el código objeto, tal como en una forma parcialmente compilada, o en cualquier otra forma deseable.
La invención también se refiere a un soporte de informaciones no extraíble, o de manera parcial o totalmente extraíble, que comprende instrucciones de un programa de ordenador, tal como se ha descrito brevemente más arriba.
Este soporte de informaciones puede ser cualquier entidad o dispositivo capaz de almacenar el programa. Por ejemplo, el soporte de informaciones puede comprender un medio de almacenamiento, tal como una ROM, por ejemplo, un CD ROM o una ROM de circuito microelectrónico, o un medio de registro magnético, tal como un disco duro, o incluso una memoria USB («USB flash drive» en inglés).
Por otro lado, el soporte de informaciones puede ser un soporte transmisible, tal como una señal eléctrica u óptica, el cual puede ser enrutado a través de un cable eléctrico u óptico, por radio o por otros medios. El programa de ordenador según la invención puede ser, en particular, descargado en una red de tipo Internet.
Como variante, el soporte de informaciones puede ser un circuito integrado en el cual se incorpora el programa, estando el circuito adaptado para ejecutar o para ser utilizado en la ejecución de uno cualquiera de los procedimientos de comunicación según la invención.

Claims (9)

REIVINDICACIONES
1. Procedimiento de comunicación en una red IP, que comprende las siguientes etapas implementadas por un dispositivo (T, T1, T2, T3) cliente capaz de implementar una conexión TCP, Transmission Control Protocol, simple y una conexión TCP de múltiples rutas:
- una etapa de descubrimiento (E1) de al menos un servidor de prueba (CHECK_SERVER) capaz de implementar una conexión TCP de múltiples rutas,
- una etapa de intento de establecimiento (E2) de al menos una conexión TCP de múltiples rutas con el servidor de prueba (CHECK_SERVER) a lo largo de al menos una ruta que permita llegar al dicho dispositivo (T, T1, T2, T3) cliente, comprendiendo la dicha etapa una determinación intercambiando datos de prueba con el servidor de prueba (CHECK_SERVER):
si las opciones TCP de múltiples rutas enviadas por el dispositivo (T, T1, T2, T3) cliente o por el servidor de prueba (CHECK_SERVER) son filtradas o modificadas por una función de servicio ubicada en el corte de flujo en la dicha ruta, o
si son recibidas correctamente por el servidor de prueba (CHECK_SERVER) o por el dispositivo (T, T1, T2, T3) cliente, - una etapa de registro (E3) de un estado (PATh_CHECKED) de la dicha ruta en cuanto a su compatibilidad con conexiones TCP de múltiples rutas, siendo el dicho estado determinado en función de un resultado de la dicha determinación por el dispositivo cliente, indicando el dicho estado una compatibilidad de la dicha ruta con conexiones TCP de múltiples rutas si se determina durante la dicha determinación que las opciones TCP de múltiples rutas son recibidas correctamente, y una incompatibilidad con conexiones TCP de múltiples rutas en caso contrario; siendo el procedimiento caracterizado porque además comprende:
- si ninguna de las rutas que permiten llegar al dicho dispositivo (T, T1, T2, T3) cliente es compatible con conexiones TCP de múltiples rutas, una etapa a lo largo de la cual el dicho dispositivo (T, T1, T2, T3) cliente utiliza el modo de transporte TCP simple para establecer una conexión con otro dispositivo cliente, o conectarse a otro dispositivo cliente, después de la recepción de un mensaje de establecimiento de una conexión de múltiples rutas enviado por este otro dispositivo cliente.
2. Procedimiento de comunicación según la reivindicación 1 que comprende, además, si el dispositivo (T, T1, T2, T3) cliente constata que al menos una de las rutas que permiten llegar a este dispositivo (T, T1, T2, T3) cliente es compatible con conexiones TCP de múltiples rutas, una etapa a lo largo de la cual el dicho dispositivo (T, T1, T2, T3) cliente utiliza opciones TCP de múltiples rutas para establecer conexiones con otro dispositivo cliente a lo largo de la dicha al menos una ruta compatible con conexiones TCP de múltiples rutas.
3. Dispositivo cliente que posee medios para implementar una conexión TCP, Transmission Control Protocol, simple y para implementar una conexión TCP de múltiples rutas, que comprende además medios para:
- descubrir al menos un servidor de prueba (CHECK_SERVER) capaz de implementar una conexión TCP de múltiples rutas,
- enviar al dicho servidor de prueba (CHECK_SERVER) una solicitud de establecimiento de una conexión TCP de múltiples rutas,
- intentar establecer al menos una conexión TCP de múltiples rutas con el dicho servidor de prueba (CHECK_SERVER) a lo largo de al menos una ruta de comunicación entre ellos, y
- registrar un estado (PATH_CHECKED) de la dicha ruta en cuanto a su compatibilidad con conexiones TCP de múltiples rutas,
comprendiendo los dichos medios para intentar establecer una conexión TCP de múltiples rutas con el dicho servidor de prueba (CHECK_SERVER) medios para determinar intercambiando datos de prueba con el servidor de prueba (CHECK_SERVER) durante el intento de establecimiento de la conexión TCP de múltiples rutas:
si las opciones TCP de múltiples rutas enviadas por el dicho dispositivo (T, T1, T2, T3, R) cliente o por el dicho servidor de prueba (CHECK_SERVER), son filtradas o modificadas por una función de servicio ubicada en el corte de flujo en la dicha ruta, o
si son recibidas correctamente por el servidor de prueba (CHECK_SERVER) o por el dispositivo (T, T1, T2, T3, R) cliente,
estando los dichos medios de registro del estado de la dicha ruta configurados para registrar un estado que indica una compatibilidad de la dicha ruta con conexiones TCP de múltiples rutas si los medios para determinar determinan que las opciones TCP de múltiples rutas se reciben correctamente, y un estado que indica una incompatibilidad con conexiones TCP de múltiples rutas en caso contrario;
siendo el dicho dispositivo cliente caracterizado porque comprende además medios para, si ninguna de las rutas que permiten llegar a dicho dispositivo (T, T1, T2, T3) cliente es compatible con conexiones TCP de múltiples rutas, utilizar el modo de transporte TCP simple para establecer una conexión con otro dispositivo cliente, o conectarse a otro dispositivo cliente, después de la recepción de un mensaje de establecimiento de una conexión de múltiples rutas enviado por este otro dispositivo cliente.
4. Dispositivo cliente según la reivindicación 3, que comprende además medios para:
- constatar que al menos una de las rutas que permiten llegar al dicho dispositivo (T, T1, T2, T3) cliente es compatible con conexiones TCP de múltiples rutas, y
- utilizar opciones TCP de múltiples rutas para establecer conexiones con otro dispositivo cliente a lo largo de la dicha ruta compatible con conexiones TCP de múltiples rutas.
5. Procedimiento de comunicación en una red IP, que comprende las siguientes etapas implementadas por un dispositivo (R) de retransmisión capaz de implementar una conexión TCP, Transmission Control Protocol, simple y una conexión TCP de múltiples rutas, estando el dicho dispositivo (R) de retransmisión conectado a un dispositivo (T) cliente capaz o no de implementar una conexión TCP de múltiples rutas:
- una etapa de descubrimiento (E1) de al menos un servidor de prueba (CHECK_SERVER) capaz de implementar una conexión TCP de múltiples rutas,
- una etapa de intento de establecimiento (E2) de al menos una conexión TCP de múltiples rutas con el servidor de prueba (CHECK_SERVER) a lo largo de al menos una ruta que permita llegar al dispositivo (R) de retransmisión, comprendiendo la dicha etapa una determinación a través del dispositivo de retransmisión, intercambiando datos de prueba con el servidor de prueba (CHECK_SERVER):
si las opciones TCP de múltiples rutas enviadas por el dispositivo (R) de retransmisión o por el servidor de prueba (CHECK_SERVER) son filtradas o modificadas por una función de servicio ubicada en el corte de flujo en la dicha ruta, o
si son recibidas correctamente por el servidor de prueba (CHECK_SERVER) o por el dispositivo (R) de retransmisión, - una etapa de registro (E3) de un estado (PATH_CHECKED) de la dicha ruta en cuanto a su compatibilidad con conexiones TCP de múltiples rutas, siendo el dicho estado determinado en función de un resultado de la dicha determinación por el dispositivo de retransmisión, indicando el dicho estado una compatibilidad de la dicha ruta con conexiones TCP de múltiples rutas si se determina durante la dicha determinación que las opciones TCP de múltiples rutas son recibidas correctamente, y una incompatibilidad con conexiones TCP de múltiples rutas en caso contrario; y - si ninguna de las rutas que permiten llegar al dicho dispositivo (R) de retransmisión distinta de su conexión al dicho dispositivo (T) cliente es compatible con conexiones TCP de múltiples rutas, una etapa a lo largo de la cual si recibe por parte del dispositivo (T) cliente un mensaje de inicialización de conexión de múltiples rutas con otro dispositivo cliente, responde al dispositivo (T) cliente no incluyendo en su respuesta ninguna opción TCP de múltiples rutas.
6. Dispositivo de retransmisión que posee medios para implementar una conexión TCP, Transmission Control Protocol, simple y para implementar una conexión TCP de múltiples rutas, estando el dicho dispositivo de retransmisión conectado a un dispositivo cliente capaz o no de implementar una conexión TCP de múltiples rutas, comprendiendo además el dicho dispositivo de retransmisión medios para:
- descubrir al menos un servidor de prueba (CHECK_SERVER) capaz de implementar una conexión TCP de múltiples rutas,
- enviar al dicho servidor de prueba (CHECK_SERVER) una solicitud de establecimiento de una conexión TCP de múltiples rutas,
- intentar establecer al menos una conexión TCP de múltiples rutas con el dicho servidor de prueba (CHECK_SERVER) a lo largo de al menos una ruta de comunicación entre ellos, y
- registrar un estado (PATH_CHECKED) de la dicha ruta en cuanto a su compatibilidad con conexiones TCP de múltiples rutas,
comprendiendo los dichos medios para intentar establecer una conexión TCP de múltiples rutas con el dicho servidor de prueba (CHECK_SERVER) medios para determinar intercambiando datos de prueba con el servidor de prueba (CHECK_SERVER) durante el intento de establecimiento de la conexión TCP de múltiples rutas:
- si las opciones TCP de múltiples rutas enviadas por el dicho dispositivo (T, T1, T2, T3, R) de retransmisión o por el dicho servidor de prueba (CHECK_SERVER), son filtradas o modificadas por una función de servicio ubicada en el corte de flujo en la dicha ruta, o
- si son recibidas correctamente por el servidor de prueba (CHECK_SERVER) o por el dispositivo (T, T1, T2, T3, R) de retransmisión, y estando los dichos medios para registrar el estado de la dicha ruta configurados para registrar un estado que indica una compatibilidad de la dicha ruta con conexiones TCP de múltiples rutas si los medios para determinar determinan que las opciones TCP de múltiples rutas son recibidas correctamente, y un estado que indica una incompatibilidad con conexiones TCP de múltiples rutas en caso contrario;
comprendiendo además el dicho dispositivo de retransmisión medios para, si ninguna de las rutas que permiten llegar al dicho dispositivo de retransmisión distinta de su conexión al dicho dispositivo (T) cliente es compatible con conexiones TCP de múltiples rutas y si recibe por parte del dicho dispositivo (T) cliente un mensaje de iniciación de conexión de múltiples rutas con otro dispositivo cliente, respondiendo al dicho dispositivo (T) cliente no incluyendo en su respuesta ninguna opción TCP de múltiples rutas.
7. Sistema que comprende:
- un servidor de prueba (CHECK_SERVER), que posee medios para implementar una conexión TCP, Transmission Control Protocol, de múltiples rutas; y
- un dispositivo (T, T1, t 2, T3, R) comunicante que comprende un dispositivo cliente según la reivindicación 3 o un dispositivo de retransmisión según la reivindicación 6 conectado a un dispositivo cliente, capaz de descubrir el dicho servidor de prueba y de establecer al menos una conexión TCP de múltiples rutas con el dicho servidor de prueba a lo largo de al menos una ruta de comunicación entre ellos.
8. Medio de almacenamiento de datos no extraíble, o de manera parcial o totalmente extraíble, que comprende instrucciones de código de programa informático para la ejecución de las etapas de un procedimiento de comunicación según una cualquiera de las reivindicaciones 1, 2 o 5, cuando las instrucciones son ejecutadas en un ordenador.
9. Programa de ordenador descargable desde una red de comunicaciones y/o almacenado en un soporte legible por ordenador y/o ejecutable por un microprocesador, que comprende instrucciones para la ejecución de las etapas de un procedimiento de comunicación según una cualquiera de las reivindicaciones 1, 2 o 5, cuando se ejecuta en un ordenador.
ES15759497T 2014-07-21 2015-07-08 Procedimiento de comunicación TCP a través de múltiples rutas entre dos terminales Active ES2930669T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1457038A FR3024004A1 (fr) 2014-07-21 2014-07-21 Procede de communication tcp via des chemins multiples entre deux terminaux
PCT/FR2015/051889 WO2016012687A1 (fr) 2014-07-21 2015-07-08 Procédé de communication tcp via des chemins multiples entre deux terminaux

Publications (1)

Publication Number Publication Date
ES2930669T3 true ES2930669T3 (es) 2022-12-21

Family

ID=51570697

Family Applications (1)

Application Number Title Priority Date Filing Date
ES15759497T Active ES2930669T3 (es) 2014-07-21 2015-07-08 Procedimiento de comunicación TCP a través de múltiples rutas entre dos terminales

Country Status (5)

Country Link
US (1) US10582020B2 (es)
EP (1) EP3172887B1 (es)
ES (1) ES2930669T3 (es)
FR (1) FR3024004A1 (es)
WO (1) WO2016012687A1 (es)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10129372B2 (en) 2015-12-08 2018-11-13 Nicira, Inc. Transferring multiple data sets using a multipath connection
US10097465B2 (en) * 2015-12-08 2018-10-09 Nicira Inc. Data transfer between endpoints using a multipath connection
US10200277B2 (en) 2015-12-08 2019-02-05 Nicira, Inc. Influencing path selection during a multipath connection
EP3482547B1 (en) * 2016-07-08 2023-11-08 Alcatel Lucent Flow aggregation and routing for multi-connectivity client devices
FR3067550A1 (fr) * 2017-06-27 2018-12-14 Orange Procede de communication quic via des chemins multiples
DE102017212256B4 (de) * 2017-07-18 2020-02-20 Volkswagen Aktiengesellschaft Verfahren und Vorrichtung zur Konfiguration von gleichartigen Netzwerkkomponenten sowie Kraftfahrzeug
KR102648720B1 (ko) * 2017-12-20 2024-03-15 주식회사 케이티 동적 터널링 기반 트래픽 전송 시스템, 그리고 이의 시그널링 방법
US10992712B2 (en) 2018-02-27 2021-04-27 Cisco Technology, Inc. Multipath subflow anchoring for security policy enforcement
CN110324206B (zh) * 2019-07-08 2021-07-09 中国联合网络通信集团有限公司 一种测评方法和系统
CN115915108A (zh) * 2021-08-05 2023-04-04 维沃移动通信有限公司 多路径通信方法、装置及终端

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8971331B2 (en) * 2009-03-24 2015-03-03 Nokia Corporation Selection of transmission parameters for wireless connection
US9455897B2 (en) * 2010-04-06 2016-09-27 Qualcomm Incorporated Cooperative bandwidth aggregation using multipath transport
EP2495927B1 (en) * 2011-03-02 2014-10-08 Alcatel Lucent Concept for providing information on a data packet association and for forwarding a data packet
CN103944691B (zh) * 2013-01-17 2019-01-15 中兴通讯股份有限公司 一种协同业务传输中的数据重传方法及接入网网关
US9456464B2 (en) * 2013-06-06 2016-09-27 Apple Inc. Multipath TCP subflow establishment and control
US9402199B2 (en) * 2013-10-14 2016-07-26 Netgear, Inc. Systems and methods for wireless load balancing and channel selection for a wireless device using WLAN modules operating simultaneously in different wireless bands

Also Published As

Publication number Publication date
WO2016012687A1 (fr) 2016-01-28
US20170163774A1 (en) 2017-06-08
EP3172887A1 (fr) 2017-05-31
FR3024004A1 (fr) 2016-01-22
EP3172887B1 (fr) 2022-08-31
US10582020B2 (en) 2020-03-03

Similar Documents

Publication Publication Date Title
ES2930669T3 (es) Procedimiento de comunicación TCP a través de múltiples rutas entre dos terminales
ES2832813T3 (es) Procedimiento de comunicación UDP a través de trayectorias múltiples entre dos terminales
ES2979115T3 (es) Método de comunicación UDP a través de múltiples vías entre dos terminales
EP2055046B1 (en) Method and device for identifying and selecting an interface to access a network
CN107534605B (zh) 用于选择网络连接集中器的方法
US10356013B2 (en) Method of emulating a multipath connection
US20170142233A1 (en) Multi-path tcp communication method between two terminals
US10868796B2 (en) Method of communication by multiple paths between two terminals
JP2015070616A (ja) 接続方法及び中継モジュール
EP2896160B1 (en) Bandwidth probing messages
EP2792126B1 (en) Virtual interface applications
ES2940469T3 (es) Método de comunicación TCP a través de múltiples rutas entre dos terminales
CN114303346A (zh) 用于管理通信网络中的终端设备的至少一个通信的方法，用于处理与通信网络中的终端设备建立的通信的方法，相对应的设备、终端设备、代理设备和计算机程序
US11252264B1 (en) Load balancing a TCP connection across multiple paths
JP2015501111A (ja) ネットワークにおける改良型ノード