ES2994033T3

ES2994033T3 - Method for tcp communication via multiple paths between two terminals

Info

Publication number: ES2994033T3
Application number: ES22203119T
Authority: ES
Inventors: Mohamed Boucadair; Christian Jacquenet
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2014-06-30
Filing date: 2015-06-29
Publication date: 2025-01-16
Anticipated expiration: 2035-06-29
Also published as: EP4398555A3; EP4142265C0; EP4142265A1; US20170142231A1; ES2940469T3; EP4398555A2; US10819830B2; FR3023105A1; PL4142265T3; WO2016001558A1; EP3162024B1; EP3162024A1; EP4142265B1

Abstract

La presente invención se refiere a un procedimiento de comunicación que comprende las siguientes etapas: a) un dispositivo cliente (T1) capaz de implementar una conexión TCP (Transmission Control Protocol) simple o una conexión multitrayecto, respectivamente un dispositivo de retransmisión (R) conectado a dicho dispositivo cliente (T1) y capaz de implementar una conexión multitrayecto, recibe (E1), en ausencia de cualquier conexión multitrayecto entre dicho dispositivo cliente (T1), respectivamente dicho dispositivo de retransmisión (R), y un determinado otro dispositivo cliente (T2, T3), información (MPTCP_STATUS) relativa a la posible compatibilidad con conexiones multitrayecto de al menos un nodo intermedio situado en un trayecto que conecta el dispositivo cliente (T1), respectivamente dicho dispositivo de retransmisión (R), a dicho otro dispositivo cliente (T2, T3); y b) el dispositivo cliente (T1) o dicho dispositivo de retransmisión (R) registra (E2) el estado (PATH_CHECKED) de dicho trayecto con respecto a su posible compatibilidad con conexiones multitrayecto. Aplicación al protocolo MPTCP (Multi-Path TCP). (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Método 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, en particular, a las redes de comunicaciones capaces de implementar el protocolo IP (Protocolo de Internet). Más en particular, la presente invención se refiere a la prestación de servicios en redes IP de "valor añadido", es decir, redes capaces de realizar distintos procesamientos de acuerdo con 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 pasarela doméstica ("Residential Gatewayen inglés), o una pasarela ubicada en una empresa, o una pasarela de operador de red("Gateway<en inglés), o un descodificador de televisión (" Set-Top Box"o STB en inglés). En aras de la brevedad, en>lo sucesivo un dispositivo cliente de cualquier tipo se denominará "terminal".

En la actualidad, terminales como los teléfonos inteligentes("smartphone"en inglés) y los ordenadores personales("Personal Computer"o PC en inglés) son capaces de activar y controlar varias interfaces lógicas vinculadas a una o varias interfaces físicas. Tales terminales se conocen como "multiinterfaz"("Multi-interface"o MIF en inglés). Cuando un terminal dispone de varias interfaces capaces de conectarlo a diferentes redes de acceso (por ejemplo, fijas, móviles o WLAN), se beneficia entonces de un acceso "híbrido", ya que combina diferentes tecnologías de red de acceso.

De este modo, se pueden asignar varias direcciones IP a estos terminales MIF para que se puedan conectar a distintos tipos de red, tales como una red fija, una red móvil o una red WLAN (iniciales de las palabras en inglés "Wireless Local Area Networkque significa "red de área local inalámbrica", de la que las redes Wi-Fi son un ejemplo emblemático), ya sea simultáneamente o en un momento posterior. Estas direcciones IP pueden:

• pertenecer a la misma familia de direcciones o a familias de direcciones diferentes (IPv4, IPv6 o ambas),

• tener diferentes duraciones de vida,

• tener diferentes alcances, por ejemplo, dirección IPv4 privada, dirección IPv6 única de alcance local(Unique LocalAddress,o ULA en inglés) o dirección IPv6 de alcance global(Global UnicastAddress,o GUA en inglés), y

• asignarse a la misma interfaz de red lógica o a diferentes interfaces de red lógicas.

Cabe señalar, no obstante, 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), de la ubicación del dispositivo o de otros factores. En particular, un dispositivo MIF puede utilizar la pluralidad de interfaces de que dispone durante el establecimiento de una conexión simple (es decir, una conexión establecida a lo largo de una única ruta con un dispositivo homólogo dado), o incluso después de haber establecido una conexión simple. También hay que señalar que un dispositivo no sabe a priori si es posible utilizar varias rutas distintas para establecer una conexión con un dispositivo homólogo dado; más concretamente, el dispositivo solo adquiere esta información (si la tiene) al final de una fase durante la cual intenta establecer una conexión utilizando varias rutas con el dispositivo homólogo.

Se considera "conexión de múltiples rutas" una conexión establecida entre dos dispositivos que utiliza simultáneamente una o varias rutas entre estos dos dispositivos. Una conexión de este tipo obedece a un protocolo dedicado, tal como MPTCP (Multi-Path TCP), que se puede definir opcionalmente como una extensión de un protocolo de transporte definido previamente, tal como TCP (iniciales de las palabras en inglés"Transmission Control Protocof\que significan "protocolo de control de transmisión"). En otras palabras, una conexión de múltiples rutas es un agregado de una o varias conexiones simples que toman la misma ruta o rutas diferentes (parcial o totalmente disjuntas).

También cabe señalar que el protocolo TCP, definido en particular en la especificación RFC 793 de la IETF (Internet Engineering Task Force), es uno de los principales protocolos utilizados por los terminales conectados a una red IP (por ejemplo, Internet), por lo que la literatura suele referirse al conjunto de protocolos "TCP/IP". El protocolo TCP permite enrutar un flujo de datos digitales de forma fiable, ordenada y sin errores entre aplicaciones que se ejecutan en terminales conectados a una red local (por ejemplo, Intranet) o a Internet. Funciona a 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 correo electrónico o para transferir archivos de un lugar a otro. Protocolos como HTTP, HTTPS, SMTP, POP3, IMAP, SSH, FTP, Telnet y muchos otros se transportan a través de conexiones TCP. Una conexión TCP se identifica por la dirección y el número de puerto del terminal de origen y por la dirección y el número de puerto del terminal de destino.

Dos terminales pueden introducir "opciones TCP" en los mensajes TCP intercambiados entre ellos para, por ejemplo, optimizar la calidad de la transmisión TCP. Dichas opciones ocupan el espacio disponible al final de la cabecera TCP y tienen una longitud("length"en inglés) expresada en octetos. 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("Máximum Segment Size",o MSS en inglés).

La llegada de los terminales MIF introduce la complejidad adicional de utilizar la totalidad o parte de las direcciones IP asignadas a través de las redes disponibles. En particular, dado que las conexiones TCP están asociadas a una dirección IP y a un número de puerto, cualquier cambio en al menos uno de estos elementos de información es susceptible de penalizar el funcionamiento de una conexión TCP en curso y, por tanto, el servicio que utiliza dicha conexión TCP. Este cambio es especialmente perjudicial cuando al terminal se le asigna una nueva dirección IP, o cuando el terminal se conecta a otra red, o cuando la interfaz a la que está asociada la dirección IP deja de estar disponible. Por ejemplo, para garantizar el mantenimiento de una conexión existente, se necesitan por tanto medios para informar a un dispositivo homólogo TCP remoto de que una dirección IP ya no es válida.

El grupo de trabajo MPTCP de la IETF se encargó en 2009 de especificar extensiones del protocolo TCP capaces de hacer frente a las limitaciones impuestas por la posibilidad de asignar varias direcciones IP a las distintas interfaces lógicas o físicas de un terminal. Este grupo de trabajo publicó las primeras especificaciones del protocolo MPTCP (véase el documento de A. Ford, C. Raiciu y M. Handley,"TCP Extensions for Multipath Operation with Múltiple Addresses",RFC 6824, enero de 2013), que algunos teléfonos inteligentes y sistemas operativos ya son capaces de implementar. La IETF tiene previsto hacer desarrollos en las especificaciones MPTCP actuales, convirtiéndolas en verdaderas normas en el sentido de la IETF.

Por lo tanto, el protocolo MPTCP se propuso para minimizar el riesgo de que una conexión TCP se interrumpa inesperadamente como consecuencia de dichos cambios de direccionamiento y, de forma más general, para satisfacer los requisitos de un contexto en el que un terminal tiene la capacidad de conectarse a una o varias redes a través de una o varias interfaces. En particular, el protocolo MPTCP responde a la necesidad de garantizar la continuidad de la sesión cuando el terminal es móvil. Se pueden contemplar varios casos de uso para el protocolo MPTCP, tales como:

• transferir tráfico entre varios puntos de acceso WLAN,

• liberar una red móvil y conmutar el tráfico hacia un punto de acceso WLAN,

• agregar varios enlaces de acceso,

• equilibrar la carga entre varias rutas, y

• optimizar el uso de los recursos de red.

A este respecto, cabe señalar (véase Wikipedia) que la "agregación de enlaces" es, en el ámbito de las redes, un concepto que describe la agrupación de varias interfaces de red como si fueran una sola, con el objetivo de aumentar el rendimiento más allá de los límites de un único enlace y, posiblemente, garantizar que otras interfaces tomen el relevo si falla un enlace de red (principio de redundancia).

Un ejemplo particularmente ventajoso de la aplicación del protocolo MPTCP es la transferencia de archivos de gran tamaño utilizando los recursos del protocolo FTP (File Transfer Protocol). Un dispositivo que actúe como cliente FTP puede utilizar dinámicamente todas las rutas disponibles que le permitan acceder a un servidor FTP, siempre que este último sea capaz de implementar las distintas conexiones MPTCP establecidas por el cliente FTP. De este modo, el tiempo de transferencia de datos se reduce considerablemente en comparación con una conexión TCP.

En el contexto MPTCP, una conexión TCP basada en la utilización de uno de los pares disponibles (dirección IP, número de puerto) se denomina "subsesión". Como resultado, una conexión MPTCP es un agregado de subsesiones TCP A modo 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 interfaces dedicadas, denominadas API(Application Programming Interface),para interactuar con las capas TCP e IP. La API clásica presentada a las aplicaciones TCP/IP es la interfaz"sockef.Un"sockefse caracteriza por varios "atributos" tales como"Local Socket Address”, "Remote Socket Address"y"Protocol".La IETF ha especificado nuevas extensiones (API MPTCP) en el documento RFC 6897 para permitir a las aplicaciones controlar las conexiones MPTCP.Cabe señalar que la API MPTCP es una extensión de la API 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 anteriormente, se proporciona un valor a 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 MPTCP.

Una conexión MPTCP se inicializa como cualquier conexión TCP convencional, salvo que la opción MP_CAPABLE (que significa que el terminal emisor es compatible con las extensiones MPTCP) se incluye en el mensaje que contiene el indicador de inicialización de la conexión (SYN) y en los mensajes posteriores. Un terminal MPTCP puede indicar la disponibilidad de una dirección IP adicional al terminal remoto utilizando la opción ADD_ADDR, sin crear necesariamente una subsesión asociada.

Sin embargo, la indicación de que varias direcciones IP están disponibles y se pueden utilizar para la comunicación con un dispositivo homólogo puede provocar que no se establezcan determinadas subsesiones TCP, ya que las direcciones IP externas percibidas por los terminales remotos pueden no ser las mismas que las visibles localmente. Por este motivo, la opción ADD_ADDR del protocolo MPTCP comprende un identificador de dirección ("Address ID") que sirve para identificar de forma inequívoca una dirección IP disponible. Esta disposición está destinada, de acuerdo con el estado de la técnica, a evitar los problemas causados por la presencia de un NAT (iniciales de las palabras en inglés"Network Address Translater\que significan "convertidor de direcciones de red") en la ruta seguida por los paquetes entre los dos terminales que han establecido una conexión MPTCP. La opción ADD_ADDR también se utiliza para transmitir un número de puerto si uno de los terminales MPTCP no utiliza el mismo número de puerto para todas las direcciones IP disponibles.

Del mismo modo, el protocolo MPTCP incluye disposiciones destinadas a permitir, en concreto, atravesar un cortafuegos("firewall'en inglés). Más concretamente, la especificación del protocolo MPTCP estipula que los números de secuencia indicados en la cabecera TCP son específicos de cada subsesión, mientras que el número de secuencia indicado en la opción DSS("Data Sequence Signal")del protocolo MPTCP se utiliza para asociar estas subsesiones a la misma conexión MPTCP.

El protocolo MPTCP está diseñado para hacer frente a la proliferación masiva de"middle boxes"(equipos intermediarios en una cadena de comunicaciones), como los NAT y los cortafuegos, en las redes actuales. Además, el documento RFC 6824 establece que si un intento de establecer una conexión MPTCP falla, la conexión se transforma automáticamente en una conexión TCP simple.

El documento de G. Hampel et al. titulado "MPTCP Proxies and Anchors; draft-hampel-mptcp-proxies-anchors-00", del 8 de febrero de 2012, describe dos tipos de funciones de red MPTCP.

Desafortunadamente, a pesar de todas estas precauciones, pueden surgir otros problemas al intentar establecer una conexión MPTCP. Por ejemplo:

• algunas o todas las opciones MPTCP se pueden filtrar (es decir, eliminar) por nodos intermediarios (por ejemplo, un NAT o un cortafuegos) situados en una interrupción de flujo entre dos pares MPTCP, como se ilustra en la figura 2;

• incluso si los mensajes SYN MPTCP (mencionados anteriormente) se intercambian con éxito entre dos pares MPTCP, los nodos intermediarios pueden filtrar las opciones DSS (mencionadas anteriormente) de los paquetes de datos; en este caso, como se ilustra en la figura 3, el intento de establecer una conexión MPTCP no puede tener éxito, con la consecuencia de un repliegue a una conexión TCP simple como en el caso ilustrado en referencia a la figura 2;

• puede ocurrir que una primera subsesión TCP se establezca con éxito, pero que el establecimiento de subsesiones posteriores fracase debido a la existencia de múltiples rutas compatibles con las extensiones MPTCP.

Los autores de la presente invención se han percatado de que la presencia de tales nodos intermediarios tenía el efecto de prolongar significativamente el retardo de establecimiento de las subsesiones TCP y, en consecuencia, repercutía negativamente en la calidad del servicio de comunicación, tal y como lo percibía el usuario.

La presente invención se refiere, por tanto, a un método de comunicación de acuerdo con la reivindicación independiente 1.

Cabe señalar que la invención se puede implementar mediante cualquier dispositivo cliente compatible con TCP. Este dispositivo cliente puede tener una o más direcciones externas, o una o más interfaces de red (lógicas o físicas). Sin embargo, este dispositivo cliente puede tener una sola interfaz si está ubicado detrás de un dispositivo de retransmisión (tal como un enrutador o una pasarela doméstica) conectado a una o más redes y compatible con las opciones TCP de múltiples rutas.

Los dispositivos de comunicación en cuestión (dispositivos cliente y dispositivos de retransmisión) pueden ser de cualquier tipo, por ejemplo un terminal, un enrutador o una pasarela doméstica.

Gracias a la invención, estos dispositivos de comunicación pueden descubrir las capacidades de cualquier "equipo intermediario" (tales como los mencionados anteriormente) y anticiparse al fallo de las conexiones de múltiples rutas.

El resultado es una reducción del retardo de establecimiento de conexiones de múltiples rutas y, por tanto, obviamente, una mejora significativa de la calidad de la experiencia del usuario.

Además, un dispositivo de comunicación de este tipo puede:

• ajustar su comportamiento en función de su conexión a la red (por ejemplo, en caso de conexión a una nueva red, no disponibilidad de una interfaz de red o de la detección de un "dispositivo intermediario"), y

• decidir, sin riesgo de degradar la calidad de la comunicación con su dispositivo homólogo, si activar una conexión de múltiples rutas, desactivar una conexión en curso de múltiples rutas o todas sus conexiones en curso de múltiples rutas, o añadir una nueva subsesión TCP a una conexión en curso de múltiples rutas.

Además, dicha conexión de múltiples rutas puede cumplir ventajosamente con el protocolo MPTCP, a fin de beneficiarse de las disposiciones de este protocolo, mencionadas brevemente más arriba.

De acuerdo con una primera variante, durante dicha etapa a), el dispositivo cliente, respectivamente el dispositivo de retransmisión, recibe dicha información dentro de un mensaje no solicitado difundido por dicho nodo intermediario.

Gracias a estas disposiciones, el dispositivo cliente o el dispositivo de retransmisión recibe dicha información de manera automática.

De acuerdo con una segunda variante:

• el dispositivo cliente, respectivamente el dispositivo de retransmisión, envía una solicitud a dicho nodo intermediario, y

• durante dicha etapa a), recibe dicha información en un mensaje de respuesta enviado por el nodo intermediario.

Gracias a estas disposiciones, el dispositivo cliente o el dispositivo de retransmisión puede obtener dicha información siempre que la necesite.

Cabe señalar que un dispositivo de comunicación (tal como un dispositivo cliente o un dispositivo de retransmisión) puede ser capaz de implementar las dos variantes descritas brevemente más arriba, o solo una de ellas. Además, un dispositivo de comunicación puede utilizar una de estas dos variantes para una parte de las múltiples rutas disponibles, y utilizar cualquier tercera variante para comprobar la compatibilidad de las demás rutas con las conexiones de múltiples rutas; el dispositivo de comunicación puede proceder de este modo en particular cuando algunos de los nodos intermediarios descubiertos no son adecuados para implementar ninguna de las dos variantes descritas brevemente más arriba.

De acuerdo con otras características particulares, si el dispositivo cliente, respectivamente dicho dispositivo de retransmisión, determina que ninguna de las rutas que conectan el dispositivo cliente con dicho otro dispositivo cliente es compatible con conexiones de múltiples rutas, dicho método comprende además una etapa en la que el dispositivo cliente utiliza una conexión TCP simple para:

• establecer una conexión con dicho otro dispositivo cliente, o

• conectarse al otro dispositivo cliente, tras la recepción de un mensaje de establecimiento de una conexión de múltiples rutas enviado por el otro dispositivo cliente.

Gracias a estas disposiciones, se evita el retardo que podría causar un intento de establecer una conexión de múltiples rutas a lo largo de una ruta incompatible con una conexión de este tipo.

Por otra parte, de acuerdo con la invención, si el dispositivo cliente, respectivamente dicho dispositivo de retransmisión, determina que al menos una de las rutas que conectan el dispositivo cliente con dicho otro dispositivo cliente es compatible con las conexiones de múltiples rutas, dicho método comprende además una etapa durante la cual el dispositivo cliente, respectivamente el dispositivo de retransmisión, utiliza un protocolo de conexión de múltiples rutas para comunicarse con dicho otro dispositivo cliente a lo largo de dicha ruta compatible con las conexiones de múltiples rutas.

En particular, los dos pares podrán establecer una conexión de múltiples rutas entre ellos a lo largo de una ruta que antes se consideraba incompatible con una conexión de este tipo, si han cambiado las circunstancias que antes provocaban un repliegue hacia una conexión TCP simple.

Cabe señalar que la invención está dirigida en particular al caso en que existan al menos dos posibles rutas de comunicación entre un primer dispositivo cliente y un segundo dispositivo cliente, aunque solo haya una ruta que se pueda utilizar al iniciar una conexión TCP. Preferentemente, la invención se implementará para cada una de las posibles rutas de comunicación entre los dos dispositivos-cliente, tras el descubrimiento de esta ruta por uno u otro de estos dispositivos-cliente; de este modo, se aprovecharán al máximo las posibilidades que ofrecen las conexiones de múltiples rutas.

De manera correspondiente, la invención se refiere a un dispositivo de comunicación de acuerdo con la reivindicación independiente 6.

De acuerdo con características particulares, dicho dispositivo de comunicación comprende además medios para:

• enviar una solicitud a dicho nodo intermediario, y

• recibir dicha información en un mensaje de respuesta enviado por el nodo intermediario.

De acuerdo con otras características particulares, dicho dispositivo de comunicación comprende un dispositivo cliente, tal como un terminal de usuario.

De acuerdo con características aún más particulares, dicho dispositivo de comunicación comprende además medios para:

• determinar que ninguna ruta que conecte dicho dispositivo de comunicación con dicho otro dispositivo cliente es compatible con conexiones de múltiples rutas, y

• utilizar una conexión TCP simple para:

o establecer una conexión con el otro dispositivo cliente, o

o conectarse al otro dispositivo cliente, tras la recepción de un mensaje de establecimiento de una conexión de múltiples rutas enviado por el otro dispositivo cliente.

De acuerdo con características de la invención, dicho dispositivo de comunicación comprende medios para:

• determinar que al menos una ruta que conecte dicho dispositivo de comunicación con dicho otro dispositivo cliente es compatible con conexiones de múltiples rutas, y

• utilizar un protocolo de conexión de múltiples rutas para comunicarse con el otro dispositivo cliente a lo largo de dicha ruta compatible con conexiones de múltiples rutas.

De acuerdo con otras características particulares, dicho dispositivo de comunicación comprende un dispositivo de retransmisión, tal como un enrutador o una pasarela doméstica, conectado a un dispositivo cliente.

• determinar que ninguna ruta que lo conecte con dicho otro dispositivo cliente es compatible con conexiones de múltiples rutas, y

• si recibe un mensaje de inicialización de conexión de múltiples rutas desde dicho dispositivo cliente al otro dispositivo cliente, responder al dispositivo cliente sin utilizar un protocolo de conexión de múltiples rutas en su respuesta.

Gracias a estas disposiciones, el dispositivo cliente al que está conectado el dispositivo de retransmisión pasa entonces, sin demora, a una conexión TCP simple.

Las ventajas que ofrecen estos dispositivos de comunicación son esencialmente las mismas que las que ofrecen los métodos correspondientes descritos brevemente más arriba.

Cabe señalar que es posible implementar 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 informático descargable desde una red de comunicaciones y/o almacenado en un soporte legible por ordenador y/o ejecutable mediante un microprocesador. Este programa informático se caracteriza porque comprende instrucciones para ejecutar las etapas del método de comunicación descrito brevemente más arriba, cuando se ejecuta en un ordenador.

Las ventajas que ofrece este programa informático son, en esencia, las mismas que las que ofrece dicho método.

Otros aspectos y ventajas de la invención se pondrán de manifiesto con la lectura de la descripción detallada a continuación de formas de realización particulares, dadas a modo de ejemplos no restrictivos. La descripción hace referencia a las figuras adjuntas, en las que:

• la figura 1, descrita anteriormente, representa un conjunto de subsesiones TCP que forman una única conexión MPTCP,

• la figura 2, descrita anteriormente, representa el fracaso de un intento de establecer una subsesión MPTCP hacia el terminal B desde un terminal A, tras el filtrado de las opciones MPTCP por los nodos intermediarios,

• la figura 3, descrita anteriormente, representa el fracaso de un intento de establecer una subsesión MPTCP hacia el terminal B desde un terminal A, tras el filtrado de las opciones DSS por los nodos intermediarios,

• la figura 4 ilustra un ejemplo de aplicación de la invención en una configuración de red que comprende tres terminales T1, T2 y T3,

• la figura 5 ilustra las subsesiones TCP establecidas entre los terminales T1 y T3 de la figura 4, y

• la figura 6 ilustra un ejemplo de aplicación de la invención en una configuración de red que comprende un terminal situado detrás de un dispositivo de retransmisión.

El descubrimiento de varias rutas que conectan un terminal dado con un dispositivo homólogo dado se puede llevar a cabo, por ejemplo, mediante un protocolo de asignación dinámica de direcciones IP, como DHCP (Dynamic Host Configuration Protocol), o mediante un mecanismo de creación de correlaciones, tal como PCP (Port Control Protocol), UPnP (Universal Plug and Play), IGD (Internet Gateway Device) o STUN (Session Traversal Utilities for NAT). A este respecto, por "correlación" se entiende 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 una función NAT, la dirección IP interna y el número de puerto interno son los datos de entrada, mientras que la dirección IP externa y el número de puerto externo son asignados por la función NAT. En el caso de un cortafuegos, la información interna y externa es idéntica. Una correlación puede incluir otra información, tal como la dirección IP y el número de puerto del dispositivo homólogo 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 que el primer dispositivo cliente desee establecer una conexión de múltiples rutas, o solo por uno de los mismos; en el segundo caso, el otro dispositivo cliente puede implementar entonces un proceso distinto del método de acuerdo con la invención para averiguar la compatibilidad de las rutas que conectan estos dos dispositivos cliente con conexiones de múltiples rutas.

La invención propone un nuevo atributo que se incluirá en las tablas de conexión de múltiples rutas. Este atributo, que se denominará "PATH_CHECKED", se establece en "1" para indicar que una subsesión TCP es compatible con las extensiones de múltiples rutas, y en "0" en caso contrario.

La invención se aplica, en general, a cualquier protocolo relativo a conexiones de múltiples rutas. A continuación se describirá la aplicación de la invención en el protocolo MPTCP descrito brevemente más arriba. En particular, la API MPTCP, mencionada anteriormente, se debe modificar para que el valor del atributo PATH_CHECKED se pueda transmitir a las aplicaciones, de acuerdo con la invención.

El protocolo MPTCP comprende normalmente una serie de disposiciones, entre las que se incluye, en particular, la definición de las siguientes opciones TCP:

• MP_CAPABLE: esta opción se utiliza para indicar al terminal remoto que el terminal emisor es compatible con las opciones MPTCP;

• ADD_ADDR: esta opción se utiliza para añadir una nueva dirección; comprende un campo opcional de dos octetos que también se puede utilizar para proporcionar un número de puerto, si es necesario;

• REMOVE_ADDR: esta opción se utiliza para eliminar una dirección;

• MP_PRIO: esta opción se utiliza para cambiar la prioridad de una conexión;

• MP_JOIN: esta opción se utiliza para identificar la conexión TCP que 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 activarse en varios modos:

•modo nativo:dos terminales MPTCP establecen todas las subsesiones correspondientes a los números de dirección/puerto disponibles y utilizan todas estas subsesiones;

•modo primario:dos terminales MPTCP indican subsesiones, pero solo un subconjunto de estas subsesiones se utiliza realmente para la transferencia de datos;

•modo secundario:si el subconjunto "primario" de subsesiones no está disponible (o está sobrecargado), se recurre a un subconjunto "secundario" de subsesiones para garantizar la continuidad de la conexión MPTCP; y

•modo de repliegue:dos terminales MPTCP utilizan una única subsesión; en caso de fallo, el tráfico pasa a una nueva subsesión creada a tal efecto.

A continuación se describirá una forma de realización del método de comunicación de acuerdo con la invención. Esta forma de realización, que se supone que está implementada por un terminal T capaz de utilizar los recursos del protocolo MPTCP, comprende las siguientes etapas.

Durante una etapa E1, el terminal T recibe información relativa a las capacidades, en términos de compatibilidad con las opciones MPTCP, de nodos intermediarios (por ejemplo, NAT, cortafuegos, etc.) situados en una interrupción de flujo en las rutas que permiten llegar al terminal.

De acuerdo con una primera variante (modo "ANNOUNCE"), un nodo intermediario difunde información sobre su posible compatibilidad con las opciones MPTCP mediante mensajes del tipo previsto, por ejemplo, mediante el protocolo SLP (Service Location Protocol) o del tipo ANNOUNCE PCP (Port Control Protocol). Cada mensaje de este tipo contiene un indicador (MPTCP_STATUS) que sirve para notificar a los terminales la compatibilidad del nodo intermediario con las conexiones MPTCP. El nodo intermediario envía estos mensajes, por ejemplo, a intervalos regulares (por ejemplo, 30 minutos), o cuando el nodo intermediario se pone en marcha o se reinicia, o en caso de actualización del software o cambio de configuración del nodo intermediario, o tras la detección de la conexión de un terminal a la red.

De acuerdo con una segunda variante (modo "PULL"), el terminal T descubre primero los nodos intermediarios y, a continuación, envía una solicitud a cada nodo intermediario así descubierto (por ejemplo, utilizando un protocolo como PCP) para recuperar información acerca de la posible compatibilidad del nodo intermediario con las opciones MPTCP. En respuesta a una solicitud de este tipo, el nodo intermediario responde con un mensaje que contiene un indicador (MPTCP_STATUS) utilizado para notificar al terminal solicitante su estado respecto a la compatibilidad de este nodo intermediario con las conexiones MPTCP.

Este indicador MPTCP_STATUS se puede definir, por ejemplo, de la siguiente manera. Un valor "0" indica que todas las opciones MPTCP son filtradas (es decir, suprimidas) por el nodo intermediario. Un valor "1" indica que el nodo intermediario es capaz de interpretar todas las opciones MPTCP. Se pueden establecer valores distintos de "0" o "1" para indicar explícitamente la lista de opciones que el nodo intermediario es capaz de interpretar, en caso de que el nodo intermediario filtre solo algunas de las opciones MPTCP.

En una etapa E2, el terminal determina, para cada nodo intermediario descubierto, si dicha ruta es compatible o no con las conexiones MPTCP. En la presente forma de realización:

• si MPTCP_STATUS==1, la ruta que pasa por este nodo intermediario se considera compatible con el establecimiento y utilización de conexiones MPTCP; el terminal T actualiza su tabla de conexión MPTCP estableciendo el atributo PATH_CHECKED en "1" para indicar que esta ruta es compatible con el modo de comunicación de múltiples rutas;

• si MPTCP_STATUS!=1, la ruta que pasa por este nodo intermediario se considera incompatible con las comunicaciones MPTCP; el terminal T actualiza su tabla de conexión MPTCP estableciendo el atributo PATH_CHECKED en "0" para indicar que esta ruta no es compatible con el modo de comunicación de múltiples rutas.

A continuación, cada vez que se conecta a una nueva red o cuando se detecta un nuevo nodo intermediario, el terminal T realiza la siguiente etapa E3:

• si ninguna de las rutas para llegar al terminal T es compatible con las conexiones MPTCP (es decir, si el atributo PATH_CHECKED de todas las rutas múltiples tiene el valor "0"):

° el terminal T utiliza el modo de transporte TCP simple para establecer conexiones salientes con sus dispositivos homólogos TCP (es decir, el modo TCP de múltiples rutas está desactivado por este terminal mientras no se modifiquen favorablemente las condiciones de conexión a la red), y

° para una conexión de múltiples rutas entrante, el terminal T no incluye opciones MPTCP en los mensajes que envía a su dispositivo homólogo (es decir, el terminal se comporta como si no fuera compatible con MPTCP); tras la recepción de un mensaje de este tipo sin opciones MPTCP por parte del dispositivo homólogo del terminal T1, el corresponsal pasa sin demora a una conexión TCP simple, de acuerdo con el "modo de repliegue" convencional; y

• si 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 se establece en "1"), el terminal T utiliza las opciones MPTCP para establecer conexiones de múltiples rutas con un dispositivo homólogo a lo largo de las rutas compatibles; al hacerlo, el terminal T se abstiene de anunciar a este dispositivo homólogo cualquier ruta que sea incompatible con las conexiones MPTCP a fin de evitar el fracaso de un intento de establecer una conexión de múltiples rutas a lo largo de una de estas rutas incompatibles.

La figura 4 ilustra un ejemplo de aplicación de la invención en una configuración de red que comprende tres terminales T1, T2 y T3. En esta figura se observa:

• un terminal T1 conectado a una o más redes IP a través de n nodos de conexión (F1, F2, ..., Fn) y n redes de acceso R1, R2, ..., Rn respectivas; estos nodos de conexión pueden albergar funciones NAT, cortafuegos, etc., o ser enrutadores IP que no incorporan ninguna función de servicio avanzado tal como un NAT o un cortafuegos;

• un terminal T2 conectado a una red IP a través de un único nodo de conexión; se supone que T2 es compatible con MPTCP y tiene asignada una dirección IP única; y

• un terminal T3 conectado a una o más redes IP a través de m nodos de conexión (Fa, Fb, ..., Fm); estos nodos pueden albergar funciones NAT, cortafuegos, etc., o ser enrutadores IP que no incorporan ninguna función de servicio avanzado tal como un NAT o un cortafuegos.

El terminal T1 inicia el método de detección de capacidades funcionales de acuerdo con la presente forma de realización. Al final de este método, T1 deduce que:

°F1 filtra las opciones MPTCP,

°F2 filtra únicamente las opciones MPTCP de los paquetes de datos, y

°Fn ni filtra ni modifica ninguna de las opciones MPTCP.

T3 inicia el método de detección de capacidades funcionales de acuerdo con la presente forma de realización. Al final de este método, T3 deduce que:

°Fa filtra las opciones MPTCP,

°Fb ni filtra ni modifica ninguna de las opciones MPTCP, y

°Fm ni filtra ni modifica ninguna de las opciones MPTCP.

Las rutas MPTCP válidas entre T1 y T3 son entonces las siguientes:

• la ruta que pasa por Fn y Fb, y

• la ruta que pasa por Fn y Fm.

Los terminales T1 y T3 no podrán utilizar MPTCP si se seleccionan rutas distintas de estas dos para intercambiar datos entre T1 y T3.

Supóngase ahora que el terminal T1 quiere establecer una conexión MPTCP con el terminal T3. La figura 5 ilustra las subsesiones TCP establecidas entre T1 y T3.

El terminal T1 indica a su dispositivo homólogo que es compatible con las conexiones MPTCP, pero solo anuncia la ruta que implica a Fn. El terminal T3 indica a su dispositivo homólogo que es compatible con las conexiones de múltiples rutas, pero solo anuncia las rutas en las que intervienen Fb y Fm. Por lo tanto, T1 y T3 pueden establecer:

• una subsesión TCP que implica a Fn (lado T1) y Fb (lado T3), y

• una subsesión TCP que implica a Fn (lado T1) y Fm (lado T3).

Supóngase que el terminal T1 quiere establecer una conexión MPTCP con el terminal T2.

El terminal T1 indica a su dispositivo homólogo que es compatible con las conexiones MPTCP, pero solo anuncia la ruta que implica a Fn. El terminal T2 indica a su dispositivo homólogo que es compatible con las conexiones de múltiples rutas. Por lo tanto, T1 y T2 pueden establecer subsesiones TCP que implican a Fn (lado T1). T1 y T2 pueden utilizar números de puerto diferentes para crear nuevas subsesiones asociadas a la conexión MPTCP de múltiples rutas.

Supóngase que el terminal T3 quiere establecer una conexión MPTCP con el terminal T2.

El terminal T3 indica a su dispositivo homólogo que es compatible con las conexiones MPTCP, pero solo anuncia las rutas en las que intervienen Fb y Fm. El terminal T2 indica a su dispositivo homólogo que es compatible con las conexiones de múltiples rutas. Por lo tanto, T3 y T2 pueden establecer subsesiones TCP que implican a Fb y Fm (lado T3).

La figura 6 ilustra un ejemplo de aplicación de la invención en una configuración de red que comprende un terminal T1 compatible o no con MPTCP y situado detrás de un dispositivo de retransmisión R, tal como un enrutador o una pasarela doméstica, compatible con MPTCP.

Este dispositivo de retransmisión R está conectado a una o más redes IP a través de n nodos de conexión (F1, F2, ..., Fn) y n redes de acceso R1, R2, Rn respectivas; estos nodos de conexión pueden albergar funciones NAT, cortafuegos, etc., o ser enrutadores IP que no incorporan ninguna función de servicio avanzado tal como un NAT o un cortafuegos.

El dispositivo de retransmisión R implementa la presente invención para comunicarse con terminales remotos. El dispositivo de retransmisión R anuncia sus capacidades funcionales al terminal T1, en función de las capacidades funcionales de las funciones Fi descubiertas por el dispositivo de retransmisión R. Para ello, procede de la siguiente manera:

• si al menos una de las múltiples rutas conocidas del dispositivo de retransmisión R es compatible con las conexiones MPTCP (es decir, si el atributo PATH_CHECKED de al menos una de las múltiples rutas se establece en "1"), el dispositivo de retransmisión R envía al terminal T1 un mensaje de notificación que comprende la mención: MPTCP_STATUS=1;

• si ninguna de las múltiples rutas conocidas del dispositivo de retransmisión R es compatible con las conexiones MPTCP (es decir, si el atributo PATH_CHECKED de todas las múltiples rutas se establece en "0"), el dispositivo de retransmisión R envía al terminal T1 un mensaje de notificación que comprende la mención: MPTCP_STATUS!=1.

Cuando el terminal T1 inicializa una conexión de múltiples rutas:

• el dispositivo de retransmisión R enruta los paquetes de datos utilizando la(s) ruta(s) cuyo atributo PATH_CHECKED está establecido en "1";

• si el dispositivo de retransmisión R no tiene una ruta compatible con las conexiones MPTCP y, sin embargo, recibe un mensaje de inicialización de conexión de múltiples rutas desde el terminal T1 (esto puede ocurrir en caso de que el terminal T1 no pueda interpretar la mención MPTCP_STATUS!=1 recibida anteriormente desde el dispositivo de retransmisión R), el dispositivo de retransmisión R de acuerdo con la invención no transmite este mensaje de inicialización a su destinatario; además, el dispositivo de retransmisión R de acuerdo con la invención responde al terminal T1 (haciéndose pasar por el dispositivo homólogo del terminal T1) sin incluir ninguna opción MPTCP en su respuesta; T1 pasa sin demora a una conexión TCP simple, de acuerdo con el "modo de repliegue" convencional.

La invención se puede implementar en nodos de redes de comunicaciones, por ejemplo terminales, enrutadores, pasarelas, NAT o cortafuegos, mediante componentes de software y/o hardware.

Los componentes de software se pueden integrar en un programa informático convencional de gestión de nodos de red. Por lo tanto, como se indicó anteriormente, la presente invención también se refiere a un sistema informático. Este sistema informático comprende, de manera convencional, una unidad central de procesamiento que controla mediante señales una memoria, así como una unidad de entrada y una unidad de salida. Además, este sistema informático se puede utilizar para ejecutar un programa informático que comprende instrucciones para la implementación de cualquiera de los métodos de comunicación de acuerdo con la invención.

De hecho, la invención también hace referencia a un programa informático tal como el descrito brevemente más arriba. Este programa informático se puede almacenar en un soporte legible por ordenador y se puede ejecutar mediante 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 código fuente y código objeto, tal como en una forma parcialmente compilada, o en cualquier otra forma deseable.

La invención también hace referencia a un soporte de información no extraíble, o parcial o totalmente extraíble, que comprende instrucciones de un programa informático tal como el descrito brevemente más arriba.

Este soporte de información puede ser cualquier entidad o dispositivo capaz de almacenar el programa. Por ejemplo, el soporte de información 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 grabación magnético, tal como un disco duro o una llave USB('USB flash drive"en inglés).

Por otro lado, el soporte de información puede ser un soporte transmisible tal como una señal eléctrica u óptica, que se puede transmitir a través de un cable eléctrico u óptico, por radio o por otros medios. En particular, el programa informático de acuerdo con la invención se puede descargar de una red de tipo Internet.

De forma alternativa, el soporte de información puede ser un circuito integrado en el que se incorpora el programa, estando adaptado el circuito para ejecutar o ser utilizado en la ejecución de cualquiera de los métodos de comunicación de acuerdo con la invención.

Claims

REIVINDICACIONES

1. Método de comunicación que comprende las siguientes etapas:

a) un dispositivo de comunicación (T1,R), siendo dicho dispositivo de comunicación un dispositivo cliente (T1) capaz de implementar una conexión TCP,Transmission Control Protocol, simple o una conexión de múltiples rutas que obedece a un protocolo de transporte del modelo OSI, o un dispositivo de retransmisión (R) conectado a dicho dispositivo cliente (T1) y capaz de implementar una conexión de múltiples rutas que obedece a dicho protocolo de transporte, recibe (E1), en ausencia de cualquier conexión de múltiples rutas que obedezca a dicho protocolo de transporte entre dicho dispositivo de comunicación (T1,R) y otro dispositivo cliente (T2, T3) determinado y antes de intentar establecer una conexión de múltiples rutas que obedezca a dicho protocolo de transporte entre dicho dispositivo de comunicación y dicho otro dispositivo cliente, información (MPTCP_STATUS) relativa a la compatibilidad o no compatibilidad con conexiones de múltiples rutas que obedezcan a dicho protocolo de transporte de al menos un nodo intermediario colocado en una ruta que conecta dicho dispositivo de comunicación (T1,R) con dicho otro dispositivo cliente (T2, T3),

b) dicho dispositivo de comunicación (T1,R) registra (E2) un estado (PATH_CHECKED) de dicha ruta en cuanto a su compatibilidad o no compatibilidad con conexiones de múltiples rutas que obedecen a dicho protocolo de transporte; y

c) si dicho dispositivo de comunicación (T1,R) determina que al menos una ruta que conecta el dispositivo de<comunicación (T1,R) con dicho otro dispositivo cliente (T2, t>3)<es compatible con conexiones de múltiples rutas que>obedecen a dicho protocolo de transporte, el dispositivo de comunicación (T1,R) utiliza un protocolo de conexión de múltiples rutas para comunicarse con dicho otro dispositivo cliente (T2, T3) a lo largo de dicha ruta compatible.

2. Método de comunicación de acuerdo con la reivindicación 1,caracterizado por que, durante dicha etapa a), dicho dispositivo de comunicación (T1,R) recibe dicha información (MPTCP_STATUS) en un mensaje no solicitado difundido por dicho nodo intermediario.

3. Método de comunicación de acuerdo con la reivindicación 1,caracterizado por quedicho dispositivo de comunicación (T1,R) envía una solicitud a dicho nodo intermediario, ypor que, durante dicha etapa a), recibe dicha información (MPTCP_STATUS) en un mensaje de respuesta enviado por el nodo intermediario.

4. Método de comunicación de acuerdo con una cualquiera de las reivindicaciones 1 a 3,caracterizado por que, si dicho dispositivo de comunicación (T1,R) determina que ninguna ruta que conecta el dispositivo de comunicación (T1,R) con dicho otro dispositivo cliente (T2, T3) es compatible con conexiones de múltiples rutas que obedecen a dicho protocolo de transporte, el método comprende además una etapa (E3) durante la cual el dispositivo de comunicación (T1,R) utiliza una conexión TCP simple para:

- establecer una conexión con dicho otro dispositivo cliente (T2, T3), o

- conectarse al otro dispositivo cliente (T2, T3), tras la recepción de un mensaje de establecimiento de una conexión de múltiples rutas que obedece a dicho protocolo de transporte, enviado por el otro dispositivo cliente (T2, T3).

5. Método de comunicación de acuerdo con una cualquiera de las reivindicaciones 1 a 4,caracterizado por quedicha conexión de múltiples rutas que obedece a dicho protocolo de transporte implementa el protocolo MPTCP,Multi-Path TCP.

6. Dispositivo de comunicación que tiene medios para implementar una conexión TCP,Transmission Control Protocol,simple o una conexión de múltiples rutas que obedece a un protocolo de transporte del modelo OSI,caracterizado por quetiene además medios para:

- recibir, en ausencia de cualquier conexión de múltiples rutas que obedezca a dicho protocolo de transporte entre dicho dispositivo de comunicación y otro dispositivo cliente determinado y antes de intentar establecer una conexión de múltiples rutas que obedezca a dicho protocolo de transporte entre dicho dispositivo de comunicación y dicho otro dispositivo cliente, información (MPTCP_STATUS) acerca de la compatibilidad o no compatibilidad con conexiones de múltiples rutas que obedezcan a dicho protocolo de transporte de al menos un nodo intermediario ubicado en una ruta que conecta dicho dispositivo de comunicación con dicho otro dispositivo de comunicación,

- registrar un estado (PATH_CHECKED) de dicha ruta en cuanto a su compatibilidad o no compatibilidad con conexiones de múltiples rutas que obedecen a dicho protocolo de transporte;

- determinar que al menos una ruta que conecta dicho dispositivo de comunicación (T1,R) con dicho otro dispositivo cliente es compatible con conexiones de múltiples rutas que obedecen a dicho protocolo de transporte; y

- utilizar un protocolo de conexión de múltiples rutas para comunicarse con dicho otro dispositivo cliente (T2, T3) a lo largo de dicha ruta compatible.

7. Dispositivo de comunicación de acuerdo con la reivindicación 6,caracterizado por quecomprende además medios para:

- enviar una solicitud a dicho nodo intermediario, y

- recibir dicha información (MPTCP_STATUS) en un mensaje de respuesta enviado por el nodo intermediario.

8. Dispositivo de comunicación de acuerdo con la reivindicación 6 o la reivindicación 7,caracterizado por quecomprende un dispositivo cliente (T1, T2, T3).

9. Dispositivo de comunicación de acuerdo con la reivindicación 8,caracterizado por quecomprende además medios para:

- determinar que ninguna ruta que conecta dicho dispositivo de comunicación con dicho otro dispositivo cliente es compatible con conexiones de múltiples rutas que obedecen a dicho protocolo de transporte, y

- utilizar una conexión TCP simple para:

• establecer una conexión con el otro dispositivo cliente, o

• conectarse al otro dispositivo cliente, tras la recepción de un mensaje de establecimiento de una conexión de múltiples rutas que obedece a dicho protocolo de transporte, enviado por el otro dispositivo cliente.

10. Dispositivo de comunicación de acuerdo con la reivindicación 6 o la reivindicación 7,caracterizado por quecomprende un dispositivo de retransmisión (R) conectado a un dispositivo cliente (T1).

11. Dispositivo de comunicación de acuerdo con la reivindicación 10,caracterizado por quecomprende además medios para:

- determinar que ninguna ruta que le conecta con dicho otro dispositivo cliente es compatible con conexiones de múltiples rutas que obedecen a dicho protocolo de transporte, y

- si recibe un mensaje de inicialización de conexión de múltiples rutas que obedece a dicho protocolo de transporte desde dicho dispositivo cliente (T1) destinado al otro dispositivo cliente, responder al dispositivo cliente (T1) sin utilizar un protocolo de conexión de múltiples rutas que obedezca a dicho protocolo de transporte en su respuesta.

12. Medio de almacenamiento de datos no extraíble, o parcial o totalmente extraíble, que comprende instrucciones de código de programa informático que, cuando se ejecutan en un ordenador, hacen que éste implemente las etapas de un método de comunicación de acuerdo con una cualquiera de las reivindicaciones 1 a 5.

13. Programa informático descargable desde una red de comunicaciones y/o almacenado en un soporte legible por ordenador y/o ejecutable por un microprocesador,caracterizado por quecomprende instrucciones para ejecutar las etapas de un método de comunicación de acuerdo con una cualquiera de las reivindicaciones 1 a 5, cuando se ejecuta en un ordenador.